The compiler (in C) is allowed to assume that infinite loops eventually terminate. This can lead to these kinds of loops not actually running forever when built with an optimizing compiler.
“An iteration statement may be assumed by the implementation to terminate if its controlling expression is not a constant expression, and none of the following operations are performed in its body, controlling expression or (in the case of a for statement) its expression-3: – input/output operations – accessing a volatile object – synchronization or atomic operations."
It can, for example, simply optimize it away, assuming non-productive infinite loops are stupid and not reflective of what the code will actually do.
if its controlling expression is not a constant expression
Pretty big caveat. If I’m reading this right true definitely qualifies as a constant expression and the loop in the meme would therefore not be optimized away.
Accesses to volatile objects and calls to library I/O functions are observable behavior. The implementation may perform any transformation of a program, provided that the resulting program’s observable behavior is not changed.
So it seems that running forever isn’t an observable property that must be preserved when code is transformed.
Still, I think compilers try to not surprise the developer too badly and would recognize a trivial loop most of the time.
Yeah, that example makes it reasonable. But the optimizer can do ridiculous stuff when it proves the loop never terminates and also assume it terminates.
The most famous example of UB bullshit is when some compilers run code that is impossible to reach just because there’s an infinite loop on the file (not even in the same function).
The lovely part about UB is it’s non-causal. The compiler can go back in time and steal Halloween candy from you when you were five and still comply with the specification.
The compiler (in C) is allowed to assume that infinite loops eventually terminate. This can lead to these kinds of loops not actually running forever when built with an optimizing compiler.
ISO/IEC 9899:2017 §6.8.5 “Iteration statements”, paragraph 6:
“An iteration statement may be assumed by the implementation to terminate if its controlling expression is not a constant expression, and none of the following operations are performed in its body, controlling expression or (in the case of a for statement) its expression-3: – input/output operations – accessing a volatile object – synchronization or atomic operations."
It can, for example, simply optimize it away, assuming non-productive infinite loops are stupid and not reflective of what the code will actually do.
Pretty big caveat. If I’m reading this right
truedefinitely qualifies as a constant expression and the loop in the meme would therefore not be optimized away.There’s also this part of the standard that throws a wrench into this hypothesis:
§5.1.2.3/4: (Program execution, Observable behavior):
So it seems that running forever isn’t an observable property that must be preserved when code is transformed.
Still, I think compilers try to not surprise the developer too badly and would recognize a trivial loop most of the time.
Yeah, that example makes it reasonable. But the optimizer can do ridiculous stuff when it proves the loop never terminates and also assume it terminates.
The most famous example of UB bullshit is when some compilers run code that is impossible to reach just because there’s an infinite loop on the file (not even in the same function).
The lovely part about UB is it’s non-causal. The compiler can go back in time and steal Halloween candy from you when you were five and still comply with the specification.