interesting thread about whether it's OK to create dialects of C and C++ that zero-initialize local variables
lists.llvm.org/pipermail/cfe-
10
13
54
Conversation
my view is that the current non-initializing behavior is so clearly bad that we should allow this dialect to develop and worry about standardizing it later
11
3
56
Replying to
It's undefined behavior and defining it as zero is no more of a language dialect than guaranteeing a non-zero pattern or guaranteeing that it traps. Traps are something that can be relied upon and processed. It's no more of a language extension than any of the UBSan sanitizers.
2
2
The language leaves it up to compilers to choose how to implement implementation-defined and undefined behavior. LLVM historically didn't provide a way to get safe implementations of most undefined behaviors but -fsanitize=undefined -fsanitize-trap=undefined is exactly that.
1
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.
1
1
1
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.
there are some social processes going on that I have not yet attempted to understand
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
Show replies