There is no risk of creating a language dialect that already exists. Real world C software is already written in a dialect of C where tons of undefined behavior maps to things that manage to keep the program working. Cases that break are noticed/fixed, what's left is this stuff.
Conversation
Of course there's a risk if you add an option that makes it guaranteed in even more scenarios and not as a side effect or something else!
2
People who care about robust software will zero in production, pattern fill in debug builds and continue using warnings and dynamic checks to catch uninitialized data usage. If someone wants to be lazy and enable it + disable the warnings to get zero-on-init semantics who cares?
2
1
I don't personally care, but it isn't obvious to you how it could be become a dialect if this option is default? PLs and software in general is littered with implementation details and underspecified things that became heavily enough relied on that a dialect formed, or the base
1
language was updated to enshrine the behavior.
To be clear, I don't have a horse in this race and I didn't follow how this got started. I am a fan of this flag and would use it for production code. I am just saying that at least to be it is clear how there is more of a ...
2
Code already depended on it before the switch and the switch is being broadly used. It's not up to them. They're just being spiteful by leaving the switch. People can just patch it out downstream. It's not their job to go out of the way to add code to cripple basic features.
1
I think I lost the thread of the argument, sorry...
I don't have any stake nor or am I up to date on the drama surrounding the flags naming, possible removal or whatever.
I am just saying it as least clear to me how auto zero init can be perceived as creating the risk of a ...
1
... language dialect.
Do you disagree with anything in that claim?
1
Yes, I disagree with it. The language dialect already exists in real world C code and it's in need of compiler support to compile it in a way that's more robust / secure / safe. Clang can't create a language dialect that exists. It would only be codifying existing usage of C.
2
Well do you agree then then it risks increasing the size of the dialect, now that it's not just "this memory happened to be zero and I didn't crash" but now "there is literally a flag that guarantees it is zero and the compiler inserts instructions to zero it"?
1
I think it might very well do that but I don't see it as a risk since it's not a problem and it isn't up to Clang to decide these things one way or another. If they aren't going to provide a proper upstream project there will be a fork of LLVM addressing these political issues.
Well yeah like I said, I don't want to and can't wade into that part of it in an informed way.