Falsehoods programmers believe about undefined behavior
1–10 of 233 posts
Re: Falsehoods programmers believe about undefined behavior
#2> If my program contains UB, and the compiler produced a binary that does X, is that a compiler bug?
UB is (usually) input dependent as well. So shouldn't this be phrased as
> If the compiler produced a binary that on some input leads to UB and does X, is that a compiler bug?
Re: Falsehoods programmers believe about undefined behavior
#3> "If my program contains UB, and the compiler produced a binary that does X, is that a compiler bug?" It's not a compiler bug.
True, if the language spec is the only thing in the universe you care about. But there are better and worse things compilers can do in the presence of UB, and the big one is warning you about it when it possibly can.
There's another big discussion on the front page about signed integer overflow in particular, and gcc screwing the developer over because it was UB when they thought it was just implementation defined:
Re: Falsehoods programmers believe about undefined behavior
#4> If my program contains UB, and the compiler produced a binary that does X, is that a compiler bug? UB is (usually) input dependent as well. So shouldn't this be phrased as > If the compiler produced a binary that on some input leads to UB and does X, is that a compiler bug?
> usually
I think this is their point. :)
Re: Falsehoods programmers believe about undefined behavior
#5> Undefined behavior: Anything is allowed to happen, and you might no longer have a computer left after it all happens.
and
> The moment your program contains UB, all bets are off.
Does this include that a compiler, when it can prove that a program it compiles contains UB, erase your disk as part of the compilation process? i.e. without you ever running the compiled program.
Re: Falsehoods programmers believe about undefined behavior
#6The biggest problem with UB, as interpreted by C/C++ compilers is the unfounded belief that the spec says that you can assume any path that leads to UB is defacto incorrect and can be ignored. That's the bogus logic required for steps 13-16 to be true.
That interpretation of the specification language is clearly bogus as that means more or less all C and C++ programs can be compiled to a single return instruction - when compiler devs introduced this new new interpretation of UB, it turned out they had to then go through and add a bunch of exceptions for basics like memset, memcpy, and memmove could work without falling afoul of their invented nonsense.
Re: Falsehoods programmers believe about undefined behavior
#7> "If my program contains UB, and the compiler produced a binary that does X, is that a compiler bug?" It's not a compiler bug. True, if the language spec is the only thing in the universe you care about. But there are better and worse things compilers can do in the presence of UB, and the big one is warning you about it when it possibly can . There's another big discussion on the front page about signed integer over…
Exactly, some things are probably UB at compile time, these IMHO should by default be a compile time error.
Integer overflow is harder ofc.
Re: Falsehoods programmers believe about undefined behavior
#8> "If my program contains UB, and the compiler produced a binary that does X, is that a compiler bug?" It's not a compiler bug. True, if the language spec is the only thing in the universe you care about. But there are better and worse things compilers can do in the presence of UB, and the big one is warning you about it when it possibly can . There's another big discussion on the front page about signed integer over…
> gcc screwing the developer over because it was UB when they thought it was just implementation defined
No, the developer thought "UB" produced an integer with an undefined (but still valid integral?) value. They misunderstood what UB is, not whether or not something was UB.
Re: Falsehoods programmers believe about undefined behavior
#9> 14. Okay, but if the line with UB is unreachable (dead) code, then it's as if the UB wasn't there.
This one came as a surprise to me. Is this really (unconditionally) true? And if so, why? Seems trivial to me to ensure that UB that will never under any circumstance execute will not affect the functioning of an otherwise correct program.
Re: Falsehoods programmers believe about undefined behavior
#10> "If my program contains UB, and the compiler produced a binary that does X, is that a compiler bug?" It's not a compiler bug. True, if the language spec is the only thing in the universe you care about. But there are better and worse things compilers can do in the presence of UB, and the big one is warning you about it when it possibly can . There's another big discussion on the front page about signed integer over…
> gcc screwing the developer over because it was UB when they thought it was just implementation defined No, the developer thought "UB" produced an integer with an undefined (but still valid integral?) value. They misunderstood what UB is, not whether or not something was UB.
That's from the spec POV. On x86 for example, signed int overflow is well defined.