Re:“What the Hardware Does” Is Not What Your Program Does: U...
by cryptonector on Monday July 15, 2019 @03:19AM
(#20438780)
If 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.
[ Parent
| on HN ]
Re:“What the Hardware Does” Is Not What Your Program Does: U...
by rini17 on Monday July 15, 2019 @06:05AM
(#20439381)
Then later, after some minor unrelated change, compiler stops optimizing and it suddenly starts overflowing the stack.
How can anyone put up with that?
Re:“What the Hardware Does” Is Not What Your Program Does: U...
by mhh__ on Monday July 15, 2019 @06:22AM
(#20439440)
If 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.
Re:“What the Hardware Does” Is Not What Your Program Does: U...
by cryptonector on Monday July 15, 2019 @12:43PM
(#20442545)
I 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.