How is that not a dialect? This code will work on compilers that implement zero-init and will likely fail randomly or have vulnerabilities on compilers that don't.
Perhaps we don't have a common understanding of what a dialect is.
Conversation
They say that zero init is a dialect but initialization with any other byte pattern chosen by the developer is somehow not a dialect. That doesn't make any sense. Regardless of how a dialect is defined, either both of those are language dialects or neither of them is a dialect.
1
Similarly, if zero-init is a dialect, so is trapping or zero-or-trap. These are all ways of defining an undefined behavior which the language leaves up to compilers to handle. The -ftrivial-auto-var-init=zero switch does NOT make it correct to use uninitialized data. Still a bug.
2
as use of compiler zeroing increases, using not-explicitly-initialized data will stop being a bug, I hope. first in practice, then in the standards.
1
I don't want that and it's a separate topic than choosing how the compiler generates code. It's not what this switch provides since it just changes the code generation and doesn't disable warnings / sanitizers to make this not considered an error. Why even have a special value?
2
Could have just supported pattern initialization without being concerned with which byte pattern is chosen. As is, this is an entirely developer hostile approach where they support pattern initialization to a chosen pattern as long as it isn't the one most people want to use.
2
If you believe zeroing at the code generation level, with it still semantically not being initialized to be a dialect, then so is setting it to 0xFF. If there wasn't hostility towards developers and towards security, the switch would not have a bias against any particular value.
1
I see what you are all getting at.
Those other variants are all dialects, too in some sense. The difference is they aren't likely to be used as a dialect in practice, because the additional behavior they add or simply specify mostly isn't useful to write working programs in.
3
1
They didn't have to add any special treatment of zero. They could just delete the code special casing zero and avoid supporting 'zero' as a flag entirely since it can just be specified as another byte pattern instead. They're either all dialects or none of them are dialects.
1
The other byte patterns are presumably mostly not useful to rely on though. A programmer doesn't say "boy, I hope this counter starts out as 0xBADF00D or whatever", but zero is special, other languages zero-init, C++ zero inits in almost every other than locals, etc.
1
Patterns with at least one zero byte are a valid NUL terminated string. That's why it makes sense to guarantee a leading zero for heap and stack canaries. It doesn't mean that the language is now a dialect where non-terminated C string heap overflows are allowed.