I think this is an interesting case study in how it’s difficult to anticipate the needs of the future and not over-engineer a protocol at the same time.

This is when the timelines diverged and sent us to this place.

There’s also this part of the standard that throws a wrench into this hypothesis:

§5.1.2.3/4: (Program execution, Observable behavior):

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.

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.