You can assume whatever initialization you want when reading code, even if it's not in the standard. Is your concern that people would start writing code assuming zero-init behavior (as they already do)?
That purpose would be better served by reclassifying uninitialized reads as erroneous behavior, which they are for C++26 onwards. What useful purpose is served by having them be UB specifically?
> Is your concern that people would start writing code assuming zero-init behavior (as they already do)?
Yes, I couldn't assume that such code can be deleted safely. Not sure, if people really rely on it, given that it doesn't work.
> erroneous behavior
So they finally did the thing and made the crazy optimizations illegal?
> If the execution of an operation is specified as having erroneous behavior, the implementation is permitted to issue a diagnostic and is permitted to terminate the execution of the program.
> Recommended practice: An implementation should issue a diagnostic when such an operation is executed.
[Note 3: An implementation can issue a diagnostic if it can determine that erroneous behavior is reachable under an implementation-specific set of assumptions about the program behavior, which can result in false positives.
— end note]
I don't get it at all. The implementation is already allowed to issue diagnostics as it likes including when the line number of the input file changes. In the case of UB it is also permitted to emit code, that terminates the program. This sounds all like saying nothing. The question is what the implementation is NOT allowed to do for erroneous behaviour, that would be allowed for undefined behaviour.
Also if they do this, does that mean that most optimizations are suddenly illegal?
Well, yeah the compiler can assume UB never happens, optimizes and that can sometimes surprise the programmer. But I the programmer also program based on that assumption. I don't see how defining all the UB serves me.
UB doesn't mean there will be nasal demons. It means there can be nasal demons, if the implementation says so. It means the language standard does not define a behavior. POSIX can still define the behavior. The implementation can still define the behavior.
Plenty of things are UB just because major implementations do things wildly differently. For example:
realloc(p, 0)
Having initialization be UB means that implementations where it's zero cost can initialize them to zero, or implementations designed for safety-critical systems can initialize them to zero, or what have you, without the standard forcing all implementations to do so.
> UB doesn't mean there will be nasal demons. It means there can be nasal demons, if the implementation says so.
Rather "if the implementation doesn't say otherwise".
Generally speaking compiler writers are not mustache-twirling villains stroking a white cat thinking of the most dastardly miscompilation they could implement as punishment. Rather they implement optimisation passes hewing as close as they can to the spec's requirements. Which means if you're out of the spec's guarantees you get whatever emergent behaviour occurs when the optimisation passes run rampant.
This is both factually incorrect and philosophically unsound.
Every asm or IR instruction is emitted by the compiler. It isn't a "doesn't say otherwise" kind of thing. Whatever the motivations are, the compiler and its authors are responsible for everything that results.
"if you're out of the spec's guarantees you get whatever emergent behaviour occurs" is simply and patently not factual. There isn't a single compiler in existence for which this is true. Every compiler makes additional guarantees beyond the ISO standard, sometimes due to local dialect, sometimes due to other standards like POSIX, sometimes controlled by configuration or switches (e.g., -fwrapv).
Yeah that’s just really bad language design. Which, again, literally no modern languages do because it’s just terrible horrible awful no good very bad design.
It's describing rather than prescribing, which yeah isn't really design. Most modern languages don't even (plan to) have multiple implementations, much less a standard.
All of that implementation freedom is also available if the behavior is erroneous instead. Having it defined as UB just gets you nasal demons, which incidentally this rule leads to on modern compilers. For example:
That purpose would be better served by reclassifying uninitialized reads as erroneous behavior, which they are for C++26 onwards. What useful purpose is served by having them be UB specifically?