Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


Then later, after some minor unrelated change, compiler stops optimizing and it suddenly starts overflowing the stack.

How can anyone put up with that?


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.


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.


Not really, any expectations here are unsupported by C standards. Compiler is, by spec, allowed to do anything here.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: