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
Replying to
I disagree: it's a real dialect once people start depending on it in production.
it's a good dialect, but it's a dialect in practice even if you can use an UB-related argument to claim that it isn't.
1
3
Replying to
Code does depend on reading uninitialized data in production. The dialect of C and C++ being broadly used including to write LLVM has uninitialized variable accesses. In general, it's incorrect to compile many projects including LLVM without -ftrivial-auto-var-init=zero.
1
Replying to
I said it's no more of a dialect than filling with other byte patterns or trapping. I'm not trying to say it isn't a dialect but rather than if it is one, those other things are too. It isn't a valid argument for not allowing zero in particular, only the switch as a whole.
Replying to
well, again, I don't pretend to understand people's motivations here, and I don't think you and I disagree in any fundamental way on this matter
1
Replying to
It's extremely frustrating for me because the current situation is almost worse than if the feature had never gone upstream. Now I need to worry about them removing it or changing it to zero-or-trap instead of zero. Spent more time dealing with this than maintaining my patch.
2
1
Show replies