6 ms·

> -ftrivial-auto-var-init=pattern Would be nice if this was zero instead of pattern.

javier_e06 3y ago
In my field zeroes are a problem when there is byte shift (not aligned). Specially data transfers. Alignment corruption cannot be detected when the memory area is all zeroes. We use things like 0xaaaa will have you.
formerly_proven 3y ago
From the compiler's PoV this is buggy code so it's better to make it predictably wrong rather than unboundedly incorrect (=security issues) or predictably correct (=people rely on UB).
- woodruffw 3y ago
  On top of your reasons (which are good ones!), there’s another good reason to avoid default zero initialization in languages like C: zero is a special value for all kinds of sensitive operations (like UID 0 for root). In other words: a mitigation that initializes all values to 0 may make some uses of uninitialized variables worse than they were before.
  - google234123 3y ago
    0 is also the most common variable value probably :p hard to tell a valid state from an invalid one
    - woodruffw 3y ago
      Yes, that's why the "uninitialized" part is important; we're talking about a mitigation that would make UB potentially easier rather than harder to exploit. Having 0 as a default initialization value in a language where doing so is well defined makes perfect sense; this is primarily an issue for C and C++ (to a lesser extent).
- vbezhenar 3y ago
  UB is a property of standard. GCC implements plenty of deviations from standard. Nothing wrong with that, as long as it's explicitly documented. I'd even argue that defined behaviour is a subset of undefined behaviour. So I'd value compiler options to force well defined and "expected" behaviour instead of the current insanity. Clang "optimized" away empty loop. My MCU gets locked because of it. I have to write `b .` with assembly, because C can't cut it. It is insanity.
  - deleted 3y ago
    [deleted]
  - saagarjha 3y ago
    Optimizing out an empty loop in C is illegal.
    - Karellen 3y ago
      That doesn't fit with my understanding of the C abstract machine. Can you give any links that explain this further? (Or to the relevant part of the standard itself?)
      - dzaima 3y ago
        N1570, 6.8.5, point 6 under "Semantics": An iteration statement whose controlling expression is not a constant expression,156) that performs no input/output operations, does not access volatile objects, and performs no synchronization or atomic operations in its body, controlling expression, or (in the case of a for statement) its expression-3, may be assumed by the implementation to terminate. Namely, the "not a constant expression" restriction is important here. So an empty loop with a non-constant end test can be assumed to terminate, but a constant one (e.g. while(1){} or for(;;); ) cannot. Note that the rules in C++ on this are different, and do allow even a constant-end-condition empty loop to be assumed to terminate.
        tialaramex 3y ago
- twic 3y ago
  There is a proposal for C++ to zero-initialise automatic (ie local variables): https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2723r1.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p27... If that goes through, zeroing automatics would just be doing the same thing. (FYI the feedback section of that paper is quite funny)
  - saagarjha 3y ago
    The proposal discusses the above concern (as it should, since the author has gotten almost every version of possible concerns). Perhaps one of them will win out and alter the proposal appropriately.
  - tialaramex 3y ago
    Ideally C++ would tell people you can't do that and make it a compiler error ("Ill-formed") but my guess is that too many people insist they ought to be able to take arbitrary C++ 23 code, recompile it with C++ 26 and have that just always work even though the standard doesn't deliver that and so it won't happen. P2723 is unlikely to happen. The "Erroneous behaviour" P2795 might have a better chance. This would say it's wrong to do uninitialized reads (whereas P2723 says they are initialized to zero and thus it's not wrong) but you always get zero anyway. I think there's a fair chance WG21 manages to make everybody unhappy by kicking this can into the long grass as they have on many other controversial issues. Zero is the wrong default, it's better than UB, but it's not good. This is actually a problem in languages like Go where zero defaults are core to the language design. The correct thing is that "I didn't initialize it" won't compile. Force the programmer to write what they meant, sometimes they meant zero, or None, or 0.0 or whatever, but surprisingly often when confronted with the question the programmer realises their design is wrong and needs a design level change.
    - tsimionescu 3y ago
      > Force the programmer to write what they meant, sometimes they meant zero, or None, or 0.0 or whatever, but surprisingly often when confronted with the question the programmer realises their design is wrong and needs a design level change. I almost sympathize with your point, except we are taking about a language where `Type var;` is the explicit way to initialize many variables to a perfectly well defined value: it is the only way to call the no-arguments constructor for a variable on the stack. It's only for non-class types that this has the bizarre behavior of allocating but not setting any value. It's even worse in a language with templates: template <class T> void foo() T { T local; return local; } Can be perfectly correct OR it can be UB based on the type of T.
blackpill0w 3y ago
I guess the reasoning behind this is that using a pattern (0xFE on GCC 12.2.0) is easier to recognise in a crash dump.

In my field zeroes are a problem when there is byte shift (not aligned). Specially data transfers. Alignment corruption cannot be detected when the memory area is all zeroes. We use things like 0xaaaa will have you.

formerly_proven 3y ago

From the compiler's PoV this is buggy code so it's better to make it predictably wrong rather than unboundedly incorrect (=security issues) or predictably correct (=people rely on UB).

woodruffw 3y ago
On top of your reasons (which are good ones!), there’s another good reason to avoid default zero initialization in languages like C: zero is a special value for all kinds of sensitive operations (like UID 0 for root). In other words: a mitigation that initializes all values to 0 may make some uses of uninitialized variables worse than they were before.
- google234123 3y ago
  0 is also the most common variable value probably :p hard to tell a valid state from an invalid one
  - woodruffw 3y ago
    Yes, that's why the "uninitialized" part is important; we're talking about a mitigation that would make UB potentially easier rather than harder to exploit. Having 0 as a default initialization value in a language where doing so is well defined makes perfect sense; this is primarily an issue for C and C++ (to a lesser extent).
vbezhenar 3y ago
UB is a property of standard. GCC implements plenty of deviations from standard. Nothing wrong with that, as long as it's explicitly documented. I'd even argue that defined behaviour is a subset of undefined behaviour. So I'd value compiler options to force well defined and "expected" behaviour instead of the current insanity. Clang "optimized" away empty loop. My MCU gets locked because of it. I have to write `b .` with assembly, because C can't cut it. It is insanity.
- deleted 3y ago
  [deleted]
- saagarjha 3y ago
  Optimizing out an empty loop in C is illegal.
  - Karellen 3y ago
    That doesn't fit with my understanding of the C abstract machine. Can you give any links that explain this further? (Or to the relevant part of the standard itself?)
    - dzaima 3y ago
      N1570, 6.8.5, point 6 under "Semantics": An iteration statement whose controlling expression is not a constant expression,156) that performs no input/output operations, does not access volatile objects, and performs no synchronization or atomic operations in its body, controlling expression, or (in the case of a for statement) its expression-3, may be assumed by the implementation to terminate. Namely, the "not a constant expression" restriction is important here. So an empty loop with a non-constant end test can be assumed to terminate, but a constant one (e.g. while(1){} or for(;;); ) cannot. Note that the rules in C++ on this are different, and do allow even a constant-end-condition empty loop to be assumed to terminate.
      - tialaramex 3y ago
twic 3y ago
There is a proposal for C++ to zero-initialise automatic (ie local variables): https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2723r1.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p27... If that goes through, zeroing automatics would just be doing the same thing. (FYI the feedback section of that paper is quite funny)
- saagarjha 3y ago
  The proposal discusses the above concern (as it should, since the author has gotten almost every version of possible concerns). Perhaps one of them will win out and alter the proposal appropriately.
- tialaramex 3y ago
  Ideally C++ would tell people you can't do that and make it a compiler error ("Ill-formed") but my guess is that too many people insist they ought to be able to take arbitrary C++ 23 code, recompile it with C++ 26 and have that just always work even though the standard doesn't deliver that and so it won't happen. P2723 is unlikely to happen. The "Erroneous behaviour" P2795 might have a better chance. This would say it's wrong to do uninitialized reads (whereas P2723 says they are initialized to zero and thus it's not wrong) but you always get zero anyway. I think there's a fair chance WG21 manages to make everybody unhappy by kicking this can into the long grass as they have on many other controversial issues. Zero is the wrong default, it's better than UB, but it's not good. This is actually a problem in languages like Go where zero defaults are core to the language design. The correct thing is that "I didn't initialize it" won't compile. Force the programmer to write what they meant, sometimes they meant zero, or None, or 0.0 or whatever, but surprisingly often when confronted with the question the programmer realises their design is wrong and needs a design level change.
  - tsimionescu 3y ago
    > Force the programmer to write what they meant, sometimes they meant zero, or None, or 0.0 or whatever, but surprisingly often when confronted with the question the programmer realises their design is wrong and needs a design level change. I almost sympathize with your point, except we are taking about a language where `Type var;` is the explicit way to initialize many variables to a perfectly well defined value: it is the only way to call the no-arguments constructor for a variable on the stack. It's only for non-class types that this has the bizarre behavior of allocating but not setting any value. It's even worse in a language with templates: template <class T> void foo() T { T local; return local; } Can be perfectly correct OR it can be UB based on the type of T.

blackpill0w 3y ago

I guess the reasoning behind this is that using a pattern (0xFE on GCC 12.2.0) is easier to recognise in a crash dump.