3 ms·

It's probably worth noting that y = x + 1 will flake out if x is an int, and it's value is INT_MAX.

• joshuamorton 8y ago
  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.
  • P_I_Staker 8y ago
    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).
  • andrewprock 8y ago
    It will act consistently if the value of x is consistent. If it's not, then it could flake out on that line.
    • joshuamorton 8y ago
      If the value of x is inconsistent, you had flakyness somewhere else. That line will always act consistently, modulo solar radiation.
  • voidmain 8y ago
    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.