4 ms·

> What does “independently” mean? It means what it says on the tin. Whatever value ends up being used must not depend on the state of the program. > Are we ta

> What does “independently” mean? It means what it says on the tin. Whatever value ends up being used must not depend on the state of the program. > Are we talking about all zeros? All zeros is an option, but the intent is to allow the implementation to pick other values as it sees fit: > Note that we do not want to mandate that the specific value actually be zero (like P2723R1 does), since we consider it valuable to allow implementations to use different “poison” values in different build modes. Different choices are conceivable here. A fixed value is more predictable, but also prevents useful debugging hints, and poses a greater risk of being deliberately relied upon by programmers. > Is the implementation not permitted to use whatever arbitrary value was in memory? No, because the value in such a case can depend on the state of the program. > Why not? Doing so would defeat the purpose of the change, which is to turn nasal-demons-on-mistake into something with less dire consequences: > In other words, it is still an "wrong" to read an uninitialized value, but if you do read it and the implementation does not otherwise stop you, you get some specific value. In general, implementations must exhibit the defined behaviour, at least up until a diagnostic is issued (if ever). There is no risk of running into the consequences associated with undefined behaviour (e.g. executing instructions not reflected in the source code, time-travel optimisations) when executing erroneous behaviour. > What’s up with [[indeterminate]]? The idea is to provide a way to opt into the old full-UB behavior if you can't afford the cost of the new behavior. > I would expect “indeterminate” to mean that the variable has a value that happens to be arbitrary (and may contain sensitive data, etc), not that it turns back into actual UB. I believe the spelling matches how the term was used in previous standards. For example, from the C++23 standard [0] (italics in original): > When storage for an object with automatic or dynamic storage duration is obtained, the object has an indeterminate value, and if no initialization is performed for the object, that object retains an indeterminate value until that value is replaced. [0]: https://open-std.org/JTC1/SC22/WG21/docs/papers/2023/n4950.pdf https://open-std.org/JTC1/SC22/WG21/docs/papers/2023/n4950.p...

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.

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.