4 ms·

The "erroneous behavior" redefinition for reads of uninitialized variables is really interesting: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2795

The "erroneous behavior" redefinition for reads of uninitialized variables is really interesting: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2795r5.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p27... It does have a runtime cost. There's an attribute to force undefined behavior on read again and avoid the cost: int x [[indeterminate]]; std::cin >> x;

augusto-moura 7mo ago
Hm, I wonder if this will be a compiler flag too, probably yes, since some projects would prefer to init all variables by hand anyway.
WalterBright 7mo ago
D initializes all variables. If you don't provide an initializer, the compiler inserts the default initializer for it. But if you really, really want to leave it uninitialized, write: int x = void; where you're not writing that by accident.
- Negitivefrags 7mo ago
  That is a way better syntax. I wonder why C++ didn't adopt it.
  - jcalvinowens 7mo ago
    There's a whole section on that: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2795r5.html#optout-alts https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p27...
    - WalterBright 7mo ago
      I don't understand its claim of a "self-documentation trap". I'm surprised the "= void;" wasn't discussed. People liked it immediately in D, and other alternatives were not proposed.
      - saagarjha 7mo ago
        The syntax is probably fine but I feel that the default kind of sucks; default initialization has mostly fallen out of favor these days.
  - bluGill 7mo ago
    Because you can't adopt that syntax after the fact. there is 30 years of C++ in the real world, initializing everything by default unless you opt-in will break some performance critical code that should not initialize everything (until it is updated manually - it has to be manual because tools are not smart enough to know where something was intentionally not initialized 100% of the time) Thus the current erroneous. It means this isn't a bug (compilers used to optimized out code paths where an uninitialized value is read and this did cause real world bugs when it doesn't matter what value is read). It also means the compiler is free to put whatever value they want there - one of the goals was the various sanitizers that check for using uninitialized values need to still work - the vast majority of the time when an uninitialized value is read that is a bug in the code. There are a lot of situations where a compiler cannot tell if a variable would be used uninitialized, so we can't rely on compiler warnings (it sometimes needs solving the halting problem).
    - tialaramex 7mo ago
      > There are a lot of situations where a compiler cannot tell if a variable would be used uninitialized, so we can't rely on compiler warnings (it sometimes needs solving the halting problem). It's an explicit choice in C++ to always accept correct programs (the alternative being to always reject incorrect programs†). The committee does not have to stick by this bad decision in each C++ version, of course they aren't likely to stop making the same bad choice, but it is possible to do so. If you're allowed to take the other side, you can of course (Rust and several other languages do this) reject programs where the compiler isn't satisfied that you definitely always initialize the variable before it's value is needed. Most obviously (but it's pretty annoying, so Rust does not do this) you could insist on the initialization as part of the variable definition in the actual syntax. † You can't have both, by Rice's Theorem, Henry Rice got his PhD for figuring out how to prove this, last century, long before C++ was conceived. So you must pick, one or the other.
    - aw1621107 7mo ago
      > there is 30 years of C++ in the real world, initializing everything by default unless you opt-in will break some performance critical code that should not initialize everything ...But the change to EB in this case does initialize everything by default?
- tialaramex 7mo ago
  > If you don't provide an initializer, the compiler inserts the default initializer for it. This requires that there is a default. Several modern languages (such as Go) insist on this, it means now your types don't even model reality in this very fundamental way. Who is a person's default spouse? Even where you can imagine a default it's sometimes undesirable to have one, for example we already live in a society where somebody decided default gender is male - and it might look too much like real data, default birthday being 1 January also matches hundreds of thousands of Americans... The most likely place you go after "Everything has a default" is the billion dollar mistake because you're inclined to just incorporate "or it's default invalid" into the type definition to get your default, and when you do that everywhere needs to have "check it's valid" code added, even if we already just checked that a moment ago.
  - kwsp 7mo ago
    I don’t care that much about everything having a default (although it’s nice), but if a language insists on a default value for every type for safety, can’t you just use std::optional?
    - tialaramex 7mo ago
      I can't tell if you imagine std::optional is a value (it is not) or if you know it's a templated type but you imagine that somehow it would be OK to redefine all programs so that every type is std::optional<T> of that type instead so as to simplify initialization. Either way no, that can't work.
      - MaxBarraclough 7mo ago
        > Either way no, that can't work. Kotlin has explicit nullable types. Rust has no null, but has option types. Both languages work fine. I think your point was that neither approach could reasonably be retrofitted to C++, do I have that right?
        tialaramex 7mo ago
ozgrakkurt 7mo ago
I envy the person that will walk into a c++ codebase and see "[[indeterminate]]" on some place. And then they will need to absolutely waste their time searching and reading what "[[indeterminate]]" means. Or over time they will just learn to ignore this crap and mentally filter it out when looking at code. Just like when I was learning rust and trying to read some http code but it was impossible because each function had 5 generics and 2 traits.
- jandrewrogers 7mo ago
  What is non-obvious about “[[indeterminate]]”? That terminology has been used throughout the standards in exactly this context for ages. This just makes it explicit instead of implicit so that the compiler can know your intent.
  - ozgrakkurt 7mo ago
    I know roughly what indeterminate means in english but it is not obvious to me when I see something like this in code. So I would have to look it up and be very careful about it since I can break something easily in C++. This just makes things more difficult from the perspective of using/learning the language. Similar problem with "unsequenced" and "reproducible" attributes added in c. It sounded cool after I took the time to learn exactly (/s) what it means. But it is not worth the time to learn it. And it is not worth the cognitive load it will put on people that will read the code later imo.
    - Joker_vD 7mo ago
      I wonder if you're fine with const, constexpr and volatile also being things. I mean, "const" really doesn't mean what one would naively think (that's what "constexpr" is actually for) and the semantics of "volatile" are also widely misunderstood.
      - tialaramex 7mo ago
        Nope, not only is C++ const not a constant, C++ constexpr isn't a constant either, and C++ constinit isn't a constant, C++ consteval is closest, but it's only available for functions. const int a = 10; // Just an immutable variable named a constexpr int b = 20; // Still an immutable variable named b static constinit int c = 30; // Now it isn't even immutable For functions const says this function promises it doesn't change things, constexpr says this function is shiny and modern and has no other real meaning (hence "constexpr all the things" memes, you might as well) but consteval does mean that we're promising this must always be evaluated at compile time, so the evaluation is frozen by runtime, however only a function can have this label. Volatile is a mess because what you actually want are the volatile intrinsics, indeed you might want more (or fewer) depending on the target. If your target can do single bit hardware writes it'd be nice to provide an intrinsic for that, rather than hoping you can write in code REG |= 0x40 and have that write a single bit... which on platforms which do not have this single bit write feature that's going to compile to an unsynchronized read-modify-write which may cause problems. However instead of having intrinsics C's volatile was hacked into the type system instead and C++ tries to keep that.
amluto 7mo ago
On a quick read of the paper, I see two surprising things: 1. If there’s no initializer and various conditions are met, then “the bytes have erroneous values, where each value is determined by the implementation independently of the state of the program. What does “independently” mean? Are we talking about all zeros? Is the implementation not permitted to use whatever arbitrary value was in memory? Why not? 2. What’s up with [[indeterminate]]? 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.
- Dylan16807 7mo ago
  > What does “independently” mean? It can pick whatever value it wants and doesn't have to care what the program is doing. Also the value has to stay the same until it's 'replaced'. > Are we talking about all zeros? It might be, but probably won't be. What makes you bring up all zeroes? > Is the implementation not permitted to use whatever arbitrary value was in memory? Why not? (Edit: probably wrong, also affects other things I said) It can. What suggests it wouldn't be able to? > 2. What’s up with [[indeterminate]]? 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. "has a value that happens to be arbitary" would be the default without [[indeterminate]]. Well, it can also error out if the compiler wants to do that.
  - aw1621107 7mo ago
    > It can. What suggests it wouldn't be able to? "Whatever value was in memory" would be depending on the (former?) state of the program, wouldn't it?
    - Dylan16807 7mo ago
      If that's what they're going for, it's way too much weight to hang on a single vague word like that. Trying to define "state of the program" in a detailed way sounds nightmarish. Let's say I'm the implementation. If I go get fresh (but not zeroed) memory from the OS to put my stack on, the garbage in there isn't state of the program, right? If I then run a function and the function exits, is the garbage now state of the program, or is it outside the state of the program? If I want a fixed init value per address, is that allowed as a hardening feature or disallowed as being based on allocation patterns? Does the as-if rule apply, so I'm fine if the program can't know for sure where I got my arbitrary byte values from? And would that mean there's still no way to say "Don't waste time initializing it, but don't do any UB shenanigans either. (Basically, pretend it was initialized by a random number generator.)"

augusto-moura 7mo ago

Hm, I wonder if this will be a compiler flag too, probably yes, since some projects would prefer to init all variables by hand anyway.

WalterBright 7mo ago

D initializes all variables. If you don't provide an initializer, the compiler inserts the default initializer for it. But if you really, really want to leave it uninitialized, write: int x = void; where you're not writing that by accident.

Negitivefrags 7mo ago
That is a way better syntax. I wonder why C++ didn't adopt it.
- jcalvinowens 7mo ago
  There's a whole section on that: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2795r5.html#optout-alts https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p27...
  - WalterBright 7mo ago
    I don't understand its claim of a "self-documentation trap". I'm surprised the "= void;" wasn't discussed. People liked it immediately in D, and other alternatives were not proposed.
    - saagarjha 7mo ago
      The syntax is probably fine but I feel that the default kind of sucks; default initialization has mostly fallen out of favor these days.
- bluGill 7mo ago
  Because you can't adopt that syntax after the fact. there is 30 years of C++ in the real world, initializing everything by default unless you opt-in will break some performance critical code that should not initialize everything (until it is updated manually - it has to be manual because tools are not smart enough to know where something was intentionally not initialized 100% of the time) Thus the current erroneous. It means this isn't a bug (compilers used to optimized out code paths where an uninitialized value is read and this did cause real world bugs when it doesn't matter what value is read). It also means the compiler is free to put whatever value they want there - one of the goals was the various sanitizers that check for using uninitialized values need to still work - the vast majority of the time when an uninitialized value is read that is a bug in the code. There are a lot of situations where a compiler cannot tell if a variable would be used uninitialized, so we can't rely on compiler warnings (it sometimes needs solving the halting problem).
  - tialaramex 7mo ago
    > There are a lot of situations where a compiler cannot tell if a variable would be used uninitialized, so we can't rely on compiler warnings (it sometimes needs solving the halting problem). It's an explicit choice in C++ to always accept correct programs (the alternative being to always reject incorrect programs†). The committee does not have to stick by this bad decision in each C++ version, of course they aren't likely to stop making the same bad choice, but it is possible to do so. If you're allowed to take the other side, you can of course (Rust and several other languages do this) reject programs where the compiler isn't satisfied that you definitely always initialize the variable before it's value is needed. Most obviously (but it's pretty annoying, so Rust does not do this) you could insist on the initialization as part of the variable definition in the actual syntax. † You can't have both, by Rice's Theorem, Henry Rice got his PhD for figuring out how to prove this, last century, long before C++ was conceived. So you must pick, one or the other.
  - aw1621107 7mo ago
    > there is 30 years of C++ in the real world, initializing everything by default unless you opt-in will break some performance critical code that should not initialize everything ...But the change to EB in this case does initialize everything by default?
tialaramex 7mo ago
> If you don't provide an initializer, the compiler inserts the default initializer for it. This requires that there is a default. Several modern languages (such as Go) insist on this, it means now your types don't even model reality in this very fundamental way. Who is a person's default spouse? Even where you can imagine a default it's sometimes undesirable to have one, for example we already live in a society where somebody decided default gender is male - and it might look too much like real data, default birthday being 1 January also matches hundreds of thousands of Americans... The most likely place you go after "Everything has a default" is the billion dollar mistake because you're inclined to just incorporate "or it's default invalid" into the type definition to get your default, and when you do that everywhere needs to have "check it's valid" code added, even if we already just checked that a moment ago.
- kwsp 7mo ago
  I don’t care that much about everything having a default (although it’s nice), but if a language insists on a default value for every type for safety, can’t you just use std::optional?
  - tialaramex 7mo ago
    I can't tell if you imagine std::optional is a value (it is not) or if you know it's a templated type but you imagine that somehow it would be OK to redefine all programs so that every type is std::optional<T> of that type instead so as to simplify initialization. Either way no, that can't work.
    - MaxBarraclough 7mo ago
      > Either way no, that can't work. Kotlin has explicit nullable types. Rust has no null, but has option types. Both languages work fine. I think your point was that neither approach could reasonably be retrofitted to C++, do I have that right?
      - tialaramex 7mo ago

ozgrakkurt 7mo ago

I envy the person that will walk into a c++ codebase and see "[[indeterminate]]" on some place. And then they will need to absolutely waste their time searching and reading what "[[indeterminate]]" means. Or over time they will just learn to ignore this crap and mentally filter it out when looking at code. Just like when I was learning rust and trying to read some http code but it was impossible because each function had 5 generics and 2 traits.

jandrewrogers 7mo ago
What is non-obvious about “[[indeterminate]]”? That terminology has been used throughout the standards in exactly this context for ages. This just makes it explicit instead of implicit so that the compiler can know your intent.
- ozgrakkurt 7mo ago
  I know roughly what indeterminate means in english but it is not obvious to me when I see something like this in code. So I would have to look it up and be very careful about it since I can break something easily in C++. This just makes things more difficult from the perspective of using/learning the language. Similar problem with "unsequenced" and "reproducible" attributes added in c. It sounded cool after I took the time to learn exactly (/s) what it means. But it is not worth the time to learn it. And it is not worth the cognitive load it will put on people that will read the code later imo.
  - Joker_vD 7mo ago
    I wonder if you're fine with const, constexpr and volatile also being things. I mean, "const" really doesn't mean what one would naively think (that's what "constexpr" is actually for) and the semantics of "volatile" are also widely misunderstood.
    - tialaramex 7mo ago
      Nope, not only is C++ const not a constant, C++ constexpr isn't a constant either, and C++ constinit isn't a constant, C++ consteval is closest, but it's only available for functions. const int a = 10; // Just an immutable variable named a constexpr int b = 20; // Still an immutable variable named b static constinit int c = 30; // Now it isn't even immutable For functions const says this function promises it doesn't change things, constexpr says this function is shiny and modern and has no other real meaning (hence "constexpr all the things" memes, you might as well) but consteval does mean that we're promising this must always be evaluated at compile time, so the evaluation is frozen by runtime, however only a function can have this label. Volatile is a mess because what you actually want are the volatile intrinsics, indeed you might want more (or fewer) depending on the target. If your target can do single bit hardware writes it'd be nice to provide an intrinsic for that, rather than hoping you can write in code REG |= 0x40 and have that write a single bit... which on platforms which do not have this single bit write feature that's going to compile to an unsynchronized read-modify-write which may cause problems. However instead of having intrinsics C's volatile was hacked into the type system instead and C++ tries to keep that.

amluto 7mo ago

On a quick read of the paper, I see two surprising things: 1. If there’s no initializer and various conditions are met, then “the bytes have erroneous values, where each value is determined by the implementation independently of the state of the program. What does “independently” mean? Are we talking about all zeros? Is the implementation not permitted to use whatever arbitrary value was in memory? Why not? 2. What’s up with [[indeterminate]]? 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.

Dylan16807 7mo ago
> What does “independently” mean? It can pick whatever value it wants and doesn't have to care what the program is doing. Also the value has to stay the same until it's 'replaced'. > Are we talking about all zeros? It might be, but probably won't be. What makes you bring up all zeroes? > Is the implementation not permitted to use whatever arbitrary value was in memory? Why not? (Edit: probably wrong, also affects other things I said) It can. What suggests it wouldn't be able to? > 2. What’s up with [[indeterminate]]? 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. "has a value that happens to be arbitary" would be the default without [[indeterminate]]. Well, it can also error out if the compiler wants to do that.
- aw1621107 7mo ago
  > It can. What suggests it wouldn't be able to? "Whatever value was in memory" would be depending on the (former?) state of the program, wouldn't it?
  - Dylan16807 7mo ago
    If that's what they're going for, it's way too much weight to hang on a single vague word like that. Trying to define "state of the program" in a detailed way sounds nightmarish. Let's say I'm the implementation. If I go get fresh (but not zeroed) memory from the OS to put my stack on, the garbage in there isn't state of the program, right? If I then run a function and the function exits, is the garbage now state of the program, or is it outside the state of the program? If I want a fixed init value per address, is that allowed as a hardening feature or disallowed as being based on allocation patterns? Does the as-if rule apply, so I'm fine if the program can't know for sure where I got my arbitrary byte values from? And would that mean there's still no way to say "Don't waste time initializing it, but don't do any UB shenanigans either. (Basically, pretend it was initialized by a random number generator.)"