3 ms·
Wait, how does that work? Without overflow, how does the compiler prove that eventually x == 7?
by andreareina 7y ago
Wait, how does that work? Without overflow, how does the compiler prove that eventually x == 7?
- cryptonector 7y agoIf x <= 7 then the answer will be 420, but if x > 7 then behavior is undefined because x will overflow, and x is signed, and signed integer overflow is UB in C, so the compiler is free to, for example, conclude that blazeit() is never called with x > 7, thus it can prove that blazeit() always returns 420. Besides, if the compiler chooses to implement signed integer overflow much like unsigned integer overflow, then x will eventually come around to 7 anyways, so the answer must be 420.
- rini17 7y agoThen later, after some minor unrelated change, compiler stops optimizing and it suddenly starts overflowing the stack. How can anyone put up with that?
- mhh__ 7y agoIf you rely on an optimization like this, that's not a code smell as much as a code-sewer: This is one of those optimizations that a very clever compiler might be able to do interprocedurally give a certain input for example.
- cryptonector 7y agoI expect the compiler would optimize the tail recursion into a loop, so the likely worst case is not that you blow the stack but that you spin for a while.
- rini17 7y agoNot really, any expectations here are unsupported by C standards. Compiler is, by spec, allowed to do anything here.
- mhh__ 7y agoThe loop (and function) terminates when x == 7, and the compiler can show that x will be 7 at some point i.e. it knows it's on a system with overflowing integers