4 ms·
> Doing so would defeat the purpose of the change, which is to turn nasal-demons-on-mistake into something with less dire consequences What nasal demons? UB i
by amluto 7mo ago
> Doing so would defeat the purpose of the change, which is to turn nasal-demons-on-mistake into something with less dire consequences
What nasal demons?
UB is permitted to format your disk, execute arbitrary code, etc. But there’s lots of room between deterministic values and UB. For example, taking a value that does depend on the previous state of the program and calling it the “erroneous” value would give a non-UB, won’t format your hard disk solution. And it even makes quite a lot of performance sense: the value that was already in the register or at that address in memory is available for free! The difference from C++23 would be that using that value would merely be erroneous and not UB.
And I think the word “indeterminate” should have been reserved for that sort of behavior.
- aw1621107 7mo ago> What nasal demons? Those that result from the pre-C++26 behavior where use of an indeterminate value is UB. > But there’s lots of room between deterministic values and UB. That's a fair point. I do think I made a mistake in how I represented the authors' decision, as it seems the authors intentionally wanted the predictability of fixed values (italics added): > Reading an uninitialized value is never intended and a definitive sign that the code is not written correctly and needs to be fixed. At the same time, we do give this code well-defined behaviour, and if the situation has not been diagnosed, we want the program to be stable and predictable. This is what we call erroneous behaviour. > And I think the word “indeterminate” should have been reserved for that sort of behavior. Perhaps, but that'd be a departure from how the word has been/is used in the standard so there would probably be some resistance against redefining it.