C++26: Trivial infinite loops are no longer undefined behaviour

The question arose: is this program well-defined? The answer was no before C++26. An infinite loop with no side effects, such as while (true);, was once considered undefined behavior. Compilers like Clang were free to assume the loop would eventually terminate and optimize it away, leading to unexpected consequences. In Clang, the infinite loop was removed entirely, causing main to fall through to an unreachable() function, resulting in unexpected output.

This was not a compiler bug but rather undefined behavior. Recently, I learned that C++26 will address this issue with P2809R3. Trivial infinite loops, defined by specific conditions, are now well-defined. The proposal was accepted as a defect report, meaning implementations may apply the fix to earlier C++ modes as well. The forward progress guarantee, introduced in C++11, states that an implementation may assume any thread will eventually terminate, call a library I/O function, access a volatile glvalue, or perform a synchronization or atomic operation.

A while (true); loop did none of these. Under the pre-C++26 rules, an execution stuck in such a loop had undefined behavior, allowing compilers to optimize it away. C++ never adopted the extra rule from C, which stated that loops with a constant expression controlling loop should not be assumed to terminate. While (1); was well-defined in C but undefined behavior in C++.

The motivation for this change came from embedded and kernel code using halt-on-error patterns. In such cases, a fatal error would cause the program to stop, which was not well-defined behavior in C++. However, turning this deliberate halt into a cooperative yield could introduce unintended behavior in bare-metal systems. C++26 fixes this by defining trivial infinite loops as well-defined and replacing them with a call to std::this_thread::yield(), giving the loop the forward-progress semantics it previously lacked.