Hacker News Reader

Comment by andrewprock | Hacker News Reader

It's probably worth noting that

    y = x + 1

will flake out if x is an int, and it's value is INT_MAX.

View on HN

I'm pretty sure it will still act consistently. Under the same compiled binary (which a hermetic environment enforces), the undefined behavior will be consistent from run to run, since the same optimizations will be used.

That's not true in a theoretical sense (undefined behavior allows me to rewrite signed overflow to "return 7 with some probability, and `rm ~/` otherwise"), but for any modern compiler, I'd assume that the optimizations chosen where signed overflow is undefined don't involve randomness.

It may be fun to point out that the complier could technically launch a game of Tetris or rm -rf /, but is that what any mainstream compiler does? I guess the behavior could be inconsistent, but who'd design a compiler like that? Seems like it'll roll over or it won't (ie. stay stuck at INT_MAX). Good unit tests would catch this if you changed compiler, but really you should handle it explicitly (look before you leap).

It will act consistently if the value of x is consistent. If it's not, then it could flake out on that line.

If the value of x is inconsistent, you had flakyness somewhere else.

That line will always act consistently, modulo solar radiation.

Not at all. In a code path where the compiler reasons that x is definitely INT_MAX, it could simply omit this code, leaving y uninitialized and nondeterministic.

Reply on news.ycombinator.com