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?
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
there are some social processes going on that I have not yet attempted to understand
all of this (initialize to special values, keep warnings, etc.) is desirable in the short term, but I don't see it as having a future