C++26 makes an uninitialized read a defined bug

Declare int x;, read it before you assign to it, and for forty years the C++ standard said your whole program was undefined. Not “x holds some leftover value,” but “the compiler may assume this line never runs and optimize on that basis.” Compilers do exactly that. They delete the branch that depends on the read, and they propagate the impossibility backward into code that already ran, so a forgotten initialization turns into a miscompile, sometimes a security bug.

C++26 narrows the rule. Under P2795, reading an uninitialized variable is erroneous behavior, a category the standard did not have before.

What erroneous behavior guarantees

It is still a bug, and the compiler is meant to diagnose it. What changed is that it now has defined limits. The read produces a specific value the implementation picks, not an indeterminate one the optimizer is free to reason away. The compiler may not travel backward and delete the surrounding code on the assumption the read never happens. A sanitizer can trap it. You get a wrong program you can debug instead of one that quietly miscompiles.

The same source, compiled twice

The demo fills a stack frame with 0xDEADBEEF, then reads an uninitialized int in a fresh frame:

Compiled as C++26 it prints erroneous value = 0, and it prints 0 on every run and at every optimization level, even though the stack was dirty a moment earlier. GCC initializes the variable to a fixed value rather than leaving it indeterminate. Compile the same source as C++23 and it prints leftover garbage (8, when I ran it), the older indeterminate-value behavior, and reading it there is undefined. Both standards still warn with -Wuninitialized.

Opting back out

Zero-initializing every local costs something, and sometimes you want an uninitialized buffer because you are about to fill it yourself. C++26 keeps that available. Mark the variable [[indeterminate]] and you are back to an indeterminate value, now as an annotation you can grep for rather than an accident.

The change breaks no correct program. Code that never read an uninitialized variable compiles and runs as before. What it removes is the case where forgetting to initialize a variable handed the optimizer a licence to do anything at all.

Sources: P2795 “Erroneous behaviour for uninitialized reads” (Thomas Köppe) · the standard wording in [basic.indet].