Live data from Hacker News

Falsehoods programmers believe about undefined behavior

predr.ag

21–30 of 233 posts

Re: Falsehoods programmers believe about undefined behavior

#21
> Here's the list of guarantees compilers make about the outcomes of undefined behavior:

> That's the whole list. No, I didn't forget any items. Yes, seriously.

I’m a little disappointed there isn’t an empty or in the middle there. I imagine screen readers would announce something like “list, zero items”.

Re: Falsehoods programmers believe about undefined behavior

#22
13. But if the line with UB isn't executed, then the program will work normally as if the UB wasn't there.

14. Okay, but if the line with UB is unreachable (dead) code, then it's as if the UB wasn't there.

15. If the line with UB is unreachable code, then the program won't crash because of the UB.

16. If the line with UB is unreachable code, then the program will at least stop running somehow and at some point.

This is nonsense. The line with UB has to be reached for the execution to be undefined.

Re: Falsehoods programmers believe about undefined behavior

#23
post #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.

The C specification doesn't say anything about what a compiler may or may not do during compilation. It only specifies how the compiled program should behave. So, yes, the C specification allows a standard-conforming compiler to erase your disk during compilation. It even allows it to do that if your code doesn't contain UB.

What if the UB is in constexpr function used during the compilation?

Re: Falsehoods programmers believe about undefined behavior

#24

> "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…

> 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.

GCC should add -Wundefined-behaviour flag that will unconditionally print "warning: this program might or not have UB" as the first diagnostic.

Re: Falsehoods programmers believe about undefined behavior

#25

> 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.

That (or more general 13-16) also does not make sense to me. Most UB (although perhaps not all, so it may be true for some obscure UB, or ones with constant arguments) are undefined for specific dynamic conditions, so it is not 'line with UB' but more 'line with UB under specific program state', e.g. expression 'a / b;' has UB if b == 0, 'a->item' has UB if b == NULL, or 'a * 4' has UB if a is int and large enough to cause overflow. If the expression is not executed, the dynamic conditions are not there, and therefore there is no UB.

Re: Falsehoods programmers believe about undefined behavior

#26
post #22

13. But if the line with UB isn't executed, then the program will work normally as if the UB wasn't there. 14. Okay, but if the line with UB is unreachable (dead) code, then it's as if the UB wasn't there. 15. If the line with UB is unreachable code, then the program won't crash because of the UB. 16. If the line with UB is unreachable code, then the program will at least stop running somehow and at some point. This…

No it doesn't. Modern processors do out-of-order execution, so your program might be doing UB before you expect.

Re: Falsehoods programmers believe about undefined behavior

#27

> "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…

> 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. GCC should add -Wundefined-behaviour flag that will unconditionally print "warning: this program might or not have UB" as the first diagnostic.

60% of the time, it's right every time!

Re: Falsehoods programmers believe about undefined behavior

#28

It is not explained why points 31 to 36 are valid, unlike HDL synthesis tools, C compilers are pretty deterministic, same input same output, except timestamps, etc. If an UB adopt X behavior one time, a reproducible build will take same X behavior the next time. Of course I am not negating the fact that this undefined in the first instance nor condoning the UB usage.

That is the observed behavior of the compiler not the defined behavior. (and while there’s some logical reason to assume that will likely continue to hold, the list is falsehoods programmers believe about undefined behavior, not observed behavior.)

Re: Falsehoods programmers believe about undefined behavior

#29

I am always amazed by articles like these. This guy thoroughly covers this topic. I cannot say I have ever written anything that ran into or caused undefined behavior. And I have programmed for a long time. Is this just an interesting topic or do people actively push the compiler to see what it will do? Maybe I am a boring/simple programmer. :)

> I cannot say I have ever written anything that ran into or caused undefined behavior.

But how would you know? :)

Re: Falsehoods programmers believe about undefined behavior

#30

I am always amazed by articles like these. This guy thoroughly covers this topic. I cannot say I have ever written anything that ran into or caused undefined behavior. And I have programmed for a long time. Is this just an interesting topic or do people actively push the compiler to see what it will do? Maybe I am a boring/simple programmer. :)

You’ve never had an integer overflow? You’ve never dereferenced a null pointer?

I suspect every C programmer invokes undefined behavior in their first 50 hours of writing C.

Post reply on HN