In C++26, reading uninitialized variables is no longer undefined, it’s “erroneous” now (What is erroneous behavior? How is it different from undefined behavior?).
However, the wording for this confuses me:
[basic.indet]/1.2
otherwise, the bytes have erroneous values, where each value is determined by the implementation independently of the state of the program.
(bold mine)
To me, this reads like the implementation must overwrite the values with something (e.g. 0xBEBEBEBE), because leaving them truly uninitialized might make them dependent on the “state of the program”, contradicting the bold part.
Is my interpretation correct? Are implementations forced to overwrite uninitialized variables now?
2
The linked P2795R5 says under Performance and security implications:
- The automatic storage for an automatic variable is always fully initialized, which has potential performance implications. P2723R1 discusses the costs in some detail. Note that this cost even applies when a class-type variable is constructed that has no padding and whose default constructor initializes all members.
- In particular, unions are fully initialized. …
It also points out that although automatic locals can be annotated [[indeterminate]] to suppress this initialization, there’s no way to avoid it for any temporaries.
So it seems like your interpretation is correct.
Oddly, it doesn’t seem important what this magic value is – or even whether this initialization really happens – except that it can’t be a trap pattern. As already pointed out there’s no magic value of a byte that is unambiguously erroneous at runtime and still safe to load, copy, and compare.
1