Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Falsehoods programmers believe about undefined behavior

predr.ag

Post reply on HN
Print view View original

11–20 of 233 posts

Re: Falsehoods programmers believe about undefined behavior

#11

Post by morelisp »

iforgotpassword wrote: post #10
morelisp wrote: post #8

Earlier quoted context omitted.

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

Both "UB" and "IB" are terms defined in the language standards, and it's obvious that's what we're talking about here.

x86 defines what specific instructions do, nothing so crass as "signed integer overflow" - that's part of why the language standard has to define it as such.

Re: Falsehoods programmers believe about undefined behavior

#12

Post by quietbritishjim »

iforgotpassword wrote: post #10
morelisp wrote: post #8

Earlier quoted context omitted.

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

That's irrelevant. A C compiler targetting x86 has no obligation at all to handle signed integer overflow in the same way the processor natively does. Because it is not an assembler - it is compiling against the theoretical C virtual machine.

This is for the same sort of reason that unsigned overflow does have a well defined meaning in C, and will always do exactly that even for targets that do not natively do that (if necessary it would emulate that behaviour in software).

Re: Falsehoods programmers believe about undefined behavior

#13

Post by Denvercoder9 »

vintermann wrote: post #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 over…

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

The problem is that this is really hard to do without producing either too much or too little warnings, as undefined behaviour is usually input-triggered; and the compiler usually doesn't know all constraints on the arguments that the programmer knows about.

For example, the function f() in the article of the other discussion is perfectly well-defined for any argument x Of course there's a point to be made that the real problem here is that the C standard makes signed integer overflow undefined behaviour, but that's not gcc's fault and can be easily worked around with -fno-strict-overflow or -Wstrict-overflow.

Re: Falsehoods programmers believe about undefined behavior

#14

Post by matkoniecz »

moring wrote: 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.

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

No, but technically compiler would not violate specification by compiling program that on running will scan your disk for secret data, publish it online, apply ransomware to your disk and deliberately destroy your SSD.

Re: Falsehoods programmers believe about undefined behavior

#15

Post by leni536 »

bjornsing wrote: post #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.

No, it isn't. The line with UB has to be reached in the execution for the execution to be undefined.

Re: Falsehoods programmers believe about undefined behavior

#16

Post by victor82 »

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.

Re: Falsehoods programmers believe about undefined behavior

#17

Post by tonetheman »

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

Re: Falsehoods programmers believe about undefined behavior

#18

Post by dottedmag »

matkoniecz wrote: post #14
moring wrote: 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.

> 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. No, but technically compiler would not violate specification by compiling program that on running will scan your disk for secret data, publish it online, apply ransomware to your disk and deliberately destroy your SSD.

Also known as "nasal demons"

Re: Falsehoods programmers believe about undefined behavior

#19

Post by Denvercoder9 »

moring wrote: 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.

Re: Falsehoods programmers believe about undefined behavior

#20

Post by [deleted] »

leni536 wrote: post #15
bjornsing wrote: post #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.

No, it isn't. The line with UB has to be reached in the execution for the execution to be undefined.

[deleted]
Post reply on HN