4 ms·

I mean sure, if I let the compiler do whatever it wants to my code in order to make it faster it'll make it faster, but then it probably won't do what I want it

I mean sure, if I let the compiler do whatever it wants to my code in order to make it faster it'll make it faster, but then it probably won't do what I want it to do. I don't understand why that's acceptable.

foxfluff 5y ago
A lot of people want programs to be optimized instead of naively executing everything as it appears in the source code. Do you think that's acceptable? I think it's easier to define in a standard what's conforming behavior than it is to exactly and precisely define all the possible optimizations a compiler may (or may not) perform. So "undefined behavior" is a decent starting point. Exceptions can be added later, but if you try to spec all allowed optimizations in advance, the spec is going to be massive and also a massive burden.
- AnIdiotOnTheNet 5y ago
  > A lot of people want programs to be optimized instead of naively executing everything as it appears in the source code. Do you think that's acceptable? Yeah, my problem isn't that optimization is changing the code per-se, it's that it is introducing a non-obvious bug by doing so. Ostensibly that loop either returns true or never returns. What if it were provided a number that would never return (assume this is possible given the algorithm provided), but because of the "optimization" now returns true? It literally gives us the wrong answer.
  - foxfluff 5y ago
    I believe it to be the case that any optimization in conjunction with a non-conforming program can lead to a subtle or hard-to-understand bug, including giving literally the wrong answer. So what is the solution? Disallow optimization, or go to hellish lengths to write a hard-to-follow spec that only permits optimizations that do not surprise people? On the other hand, it is not hard for me to incorporate into my mental model of a language that a program should eventually "do something" and if it doesn't, it is literally a wrong program. In fact, that's exactly what I thought when I saw the code in question. Before even realizing what it is about: I read it like a normal program, I saw that it can only ever return true, therefore that code can do only one thing, and all that fluff in there does not impact the end result. So I don't think it's particularly non-obvious, but it does require something from the reader. I'm ok with that, there's a lot in C and C++ you can't just assume. I call this a "weird program." It's trying to brute-force an answer out of the computer, but it's the kind of an answer that may or may not ever come. Hardly unlike a program that tries to answer the halting problem. Not necessarily an illegitimate program (bruteforcing is a legitimate way to find answers), but not the kind of thing you'd put inside a normal application. So I'm not concerned about normal applications running into this issue much. If a normal application could go into an infinite do-nothing loop, that is almost definitely a bug -- a literally wrong program. The optimization here only changes how that wrongness manifests, which is expected for UB & optimizations. I do like that C gives you the escape hatch of using a constant controlling expression if you really want a true "potentially-infinite" loop.
    - AnIdiotOnTheNet 5y ago
      > On the other hand, it is not hard for me to incorporate into my mental model of a language that a program should eventually "do something" and if it doesn't, it is literally a wrong program. Consider this hypothetical: the loop is only potentially infinite because it is written incorrectly. In testing, I would notice an infinite loop and debugging where that is happening is pretty trivial. When the compiler optimizes that away to just always return true, it has made the source of the bug much more difficult to pin down because the code I asked the compiler to make produces a completely different result than what the compiler compiled.
      - foxfluff 5y ago
        I know. I've used C for two decades, I write it professionally today. Some bugs end up being extremely difficult to debug. I accept that as a fact of life; in exchange, we get pretty decent performance. Guess what I do when there's a bug I have a hard time pinning down? Recompile with optimizations turned off. By the way, I don't think I have ever witnessed a bug caused by an accidentally-infinite loop getting optimized out. So making that almost-never-happens situation easier to fix is not worth trading any optimizations for, imo. I'd rather just get a warning from compiler/static analyzer (if the code isn't the way it is due to macro expansion).
Thiez 5y ago
Ostensibly as a programmer you know the semantics of your programming language, so the compiler isn't doing anything unexpected here ;) So from its perspective it is not doing anything unexpected to your code. I think the real problem here is that people underestimate the complexity of C and C++. It often feels like it would be easy to guess what the assembly would look like for some snippet of C/C++ code (especially when it's not using any C++ features, such as the loop in the article) when we really should be thinking in terms of the abstract machine that the standard defines.
- AnIdiotOnTheNet 5y ago
  > Ostensibly as a programmer you know the semantics of your programming language, so the compiler isn't doing anything unexpected here ;) So from its perspective it is not doing anything unexpected to your code. I just don't think having 'gotcha' rules the compiler exploits to do whatever it wants regardless of programmer intent is a good idea, and that's how C/C++ treats UB. UB should be a compiler error and force the programmer to specify what they want the result to actually be so there are no assumptions on the programmer end and no surprises from the compiler.
  - Denvercoder9 5y ago
    This happens because (paraphrased) the standard dictates that loops without side-effects eventually terminate, and all other programs have undefined behaviour. You can't turn hitting that undefined behaviour into a compiler error, as distinguishing between the two requires solving the halting problem. You can remove the whole assumption, but that limits the optimization capabilities of the compiler. That gives a trade-off: do we want actual infinite loops, or do we want better optimizations? The second seems more useful to me, even though it might sometimes give surprising behaviour for the programmer.
    - AnIdiotOnTheNet 5y ago
      > You can't turn hitting that undefined behaviour into a compiler error, as distinguishing between the two requires solving the halting problem. That's a fair point, but it still feels wrong to me that the compiler can throw away large chunks of code and change the outcome of the function silently.
tsimionescu 5y ago
Well, in this particular case, there are two possible options: the loop either terminates, or your program will forever more do nothing observable other than producing heat. In the first case the compiler is right, in the second case your program was not doing anything possibly useful anyway. So, what's the actual harm?
- AnIdiotOnTheNet 5y ago
  If the loop infinitely looping was a bug caused by not writing the function correctly, that bug is now a lot harder to find.
  - UncleMeat 5y ago
    I'm not certain that "the program should do roughly what the author expects in the face of arbitrary program incorrectness" is a thing that works in general. What should your program do if you overflow a 32 bit signed integer? What if you overflow a 64 bit signed integer? Should it do the "expected" thing and wrap according to two's complement? How do you intend to do that efficiently in a portable manner? This rabbit hole can be chased forever until you are left with every C++ implementation being a full blown interpreter.
    - tsimionescu 5y ago
      While I agree with your statement in general, I think this is not a good example. Integer arithmetic is two's complement on all platforms of any interest from the last 30+ years, and unsigned integer overflow is already well defined in the standard. It's just an arcane decision to keep signed integer overflow UB as a performance hack. This is especially true given that (a) there is no standard compliant way of checking if you had overflow, and (b) the most pedantically correct way of looping over arrays and such uses an unsigned type (size_t), negating the usual claims about optimization opportunities.
      - UncleMeat 5y ago
        Unsigned integer overflow is well defined. And because of this, you see worse performance when working with unsigned integers in many cases, because the compiler needs to stick instructions in there to catch overflow at the appropriate width. It cannot just use hardware flags because that 32 bit unsigned integer needs to wrap correctly on both 32 bit and 64 bit machines. Thus the word "efficiently" in my comment. By requiring weird and almost certainly buggy behavior to be defined, you require the program to behave more like an interpreted program, with associated performance costs.
floxy 5y ago
Sounds like you might be interested in Friendly C: https://blog.regehr.org/archives/1180 https://blog.regehr.org/archives/1180
UncleMeat 5y ago
The assumption is that programmers don't actually want to write infinite loops that do nothing but spin. UB, in most cases, is also well aligned with a typical programmer's definition of "is a bug".

foxfluff 5y ago

A lot of people want programs to be optimized instead of naively executing everything as it appears in the source code. Do you think that's acceptable? I think it's easier to define in a standard what's conforming behavior than it is to exactly and precisely define all the possible optimizations a compiler may (or may not) perform. So "undefined behavior" is a decent starting point. Exceptions can be added later, but if you try to spec all allowed optimizations in advance, the spec is going to be massive and also a massive burden.

AnIdiotOnTheNet 5y ago
> A lot of people want programs to be optimized instead of naively executing everything as it appears in the source code. Do you think that's acceptable? Yeah, my problem isn't that optimization is changing the code per-se, it's that it is introducing a non-obvious bug by doing so. Ostensibly that loop either returns true or never returns. What if it were provided a number that would never return (assume this is possible given the algorithm provided), but because of the "optimization" now returns true? It literally gives us the wrong answer.
- foxfluff 5y ago
  I believe it to be the case that any optimization in conjunction with a non-conforming program can lead to a subtle or hard-to-understand bug, including giving literally the wrong answer. So what is the solution? Disallow optimization, or go to hellish lengths to write a hard-to-follow spec that only permits optimizations that do not surprise people? On the other hand, it is not hard for me to incorporate into my mental model of a language that a program should eventually "do something" and if it doesn't, it is literally a wrong program. In fact, that's exactly what I thought when I saw the code in question. Before even realizing what it is about: I read it like a normal program, I saw that it can only ever return true, therefore that code can do only one thing, and all that fluff in there does not impact the end result. So I don't think it's particularly non-obvious, but it does require something from the reader. I'm ok with that, there's a lot in C and C++ you can't just assume. I call this a "weird program." It's trying to brute-force an answer out of the computer, but it's the kind of an answer that may or may not ever come. Hardly unlike a program that tries to answer the halting problem. Not necessarily an illegitimate program (bruteforcing is a legitimate way to find answers), but not the kind of thing you'd put inside a normal application. So I'm not concerned about normal applications running into this issue much. If a normal application could go into an infinite do-nothing loop, that is almost definitely a bug -- a literally wrong program. The optimization here only changes how that wrongness manifests, which is expected for UB & optimizations. I do like that C gives you the escape hatch of using a constant controlling expression if you really want a true "potentially-infinite" loop.
  - AnIdiotOnTheNet 5y ago
    > On the other hand, it is not hard for me to incorporate into my mental model of a language that a program should eventually "do something" and if it doesn't, it is literally a wrong program. Consider this hypothetical: the loop is only potentially infinite because it is written incorrectly. In testing, I would notice an infinite loop and debugging where that is happening is pretty trivial. When the compiler optimizes that away to just always return true, it has made the source of the bug much more difficult to pin down because the code I asked the compiler to make produces a completely different result than what the compiler compiled.
    - foxfluff 5y ago
      I know. I've used C for two decades, I write it professionally today. Some bugs end up being extremely difficult to debug. I accept that as a fact of life; in exchange, we get pretty decent performance. Guess what I do when there's a bug I have a hard time pinning down? Recompile with optimizations turned off. By the way, I don't think I have ever witnessed a bug caused by an accidentally-infinite loop getting optimized out. So making that almost-never-happens situation easier to fix is not worth trading any optimizations for, imo. I'd rather just get a warning from compiler/static analyzer (if the code isn't the way it is due to macro expansion).

Thiez 5y ago

Ostensibly as a programmer you know the semantics of your programming language, so the compiler isn't doing anything unexpected here ;) So from its perspective it is not doing anything unexpected to your code. I think the real problem here is that people underestimate the complexity of C and C++. It often feels like it would be easy to guess what the assembly would look like for some snippet of C/C++ code (especially when it's not using any C++ features, such as the loop in the article) when we really should be thinking in terms of the abstract machine that the standard defines.

AnIdiotOnTheNet 5y ago
> Ostensibly as a programmer you know the semantics of your programming language, so the compiler isn't doing anything unexpected here ;) So from its perspective it is not doing anything unexpected to your code. I just don't think having 'gotcha' rules the compiler exploits to do whatever it wants regardless of programmer intent is a good idea, and that's how C/C++ treats UB. UB should be a compiler error and force the programmer to specify what they want the result to actually be so there are no assumptions on the programmer end and no surprises from the compiler.
- Denvercoder9 5y ago
  This happens because (paraphrased) the standard dictates that loops without side-effects eventually terminate, and all other programs have undefined behaviour. You can't turn hitting that undefined behaviour into a compiler error, as distinguishing between the two requires solving the halting problem. You can remove the whole assumption, but that limits the optimization capabilities of the compiler. That gives a trade-off: do we want actual infinite loops, or do we want better optimizations? The second seems more useful to me, even though it might sometimes give surprising behaviour for the programmer.
  - AnIdiotOnTheNet 5y ago
    > You can't turn hitting that undefined behaviour into a compiler error, as distinguishing between the two requires solving the halting problem. That's a fair point, but it still feels wrong to me that the compiler can throw away large chunks of code and change the outcome of the function silently.

tsimionescu 5y ago

Well, in this particular case, there are two possible options: the loop either terminates, or your program will forever more do nothing observable other than producing heat. In the first case the compiler is right, in the second case your program was not doing anything possibly useful anyway. So, what's the actual harm?

AnIdiotOnTheNet 5y ago
If the loop infinitely looping was a bug caused by not writing the function correctly, that bug is now a lot harder to find.
- UncleMeat 5y ago
  I'm not certain that "the program should do roughly what the author expects in the face of arbitrary program incorrectness" is a thing that works in general. What should your program do if you overflow a 32 bit signed integer? What if you overflow a 64 bit signed integer? Should it do the "expected" thing and wrap according to two's complement? How do you intend to do that efficiently in a portable manner? This rabbit hole can be chased forever until you are left with every C++ implementation being a full blown interpreter.
  - tsimionescu 5y ago
    While I agree with your statement in general, I think this is not a good example. Integer arithmetic is two's complement on all platforms of any interest from the last 30+ years, and unsigned integer overflow is already well defined in the standard. It's just an arcane decision to keep signed integer overflow UB as a performance hack. This is especially true given that (a) there is no standard compliant way of checking if you had overflow, and (b) the most pedantically correct way of looping over arrays and such uses an unsigned type (size_t), negating the usual claims about optimization opportunities.
    - UncleMeat 5y ago
      Unsigned integer overflow is well defined. And because of this, you see worse performance when working with unsigned integers in many cases, because the compiler needs to stick instructions in there to catch overflow at the appropriate width. It cannot just use hardware flags because that 32 bit unsigned integer needs to wrap correctly on both 32 bit and 64 bit machines. Thus the word "efficiently" in my comment. By requiring weird and almost certainly buggy behavior to be defined, you require the program to behave more like an interpreted program, with associated performance costs.

floxy 5y ago

Sounds like you might be interested in Friendly C: https://blog.regehr.org/archives/1180 https://blog.regehr.org/archives/1180

UncleMeat 5y ago

The assumption is that programmers don't actually want to write infinite loops that do nothing but spin. UB, in most cases, is also well aligned with a typical programmer's definition of "is a bug".