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.
1
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.
I take personal offense to -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang since it's people choosing to make my life harder rather than just not special casing zero, which would have been less work and less code for them to develop and maintain upstream.
1
It also means I have to deal with people questioning why I'm using that switch and they're concerned about what I'm doing since they think it means that it's deprecated. I've had multiple people message me about it. They might change it thinking it's bad because of how it looks.
1
Show replies