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

The question of whether a program with a while (true); loop is well-defined has been answered in the negative until now. This type of loop used to be considered undefined behavior in C++ before C++26. Compilers had the freedom to assume that such loops would terminate, and as a result, they could optimize them away, leading to unexpected outcomes. For instance, in Clang, the infinite loop would be removed, causing the program to print "Hello world!" instead.

However, this behavior has been changed with the introduction of C++26. The C++ community accepted a proposal (P2809R3) that addresses this issue. Trivial infinite loops are now well-defined in C++26. These loops are defined by two conditions: the loop body is empty, and the loop's controlling expression is a constant expression that evaluates to true.

The change aims to provide better forward progress guarantees, introduced in C++11 alongside threading support. A forward-progress guarantee ensures that an execution path will eventually do one of several things: terminate, call a library I/O function, access a volatile glvalue, or perform a synchronization or atomic operation. Loops like while (true); don't fit into these categories, hence were previously considered undefined behavior.

This change doesn't simply copy C's rule about loops with constant expressions. C++26 adopts a more specific definition to avoid inhibiting useful optimizations. A trivial infinite loop is now replaced with a call to std::this_thread::yield(), which provides the forward-progress semantics it lacked previously.

The change also updates the forward progress guarantee, which now includes the option for a thread to "continue execution of a trivial infinite loop." However, this change is implementation-defined for freestanding implementations, which could potentially introduce unintended behavior in bare-metal systems. Despite these nuances, trivial infinite loops are now well-defined in C++26, eliminating the divergence from C and preventing unexpected behaviors in embedded and security-critical code.