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 ...
Conversation
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
There is no debate like this when they add support for a GCC or MSVC++ extensions for compatibility, and this switch is needed for compatibility with real world C code. If they think the switch creates the issue rather than the other way around, how do they intend to support code
1
that was written to depend upon the comparable MSVC++ switch? Also, they aren't a position to dictate these things. I patched the compiler before and will happily patch out the spiteful warning switch along with submitting a patch doing that to all the major Linux distributions.
1
I don't disagree with any of that.
I'm just curious how you can insist that this option doesn't increase the risk of people relying on it.
People rely on a ton of compiler options and extensions, and that's not a bad thing in aggregate: they are there because they are useful.
1
I don't consider it a risk. It is something that could happen, but risk implies it is a bad thing. If people are going to depend on it they should support adding *another* option that actually gives them what they want rather than using this which is incorrect. If enough people..
2
Let's just say it's a possibility then.
People who favor not creating widely-used language variants and extensions (these people exist!) may see it as a bad thing because they weigh things different than someone who wants this as a tool to write secure software (for e.g.).
1
Those people don't have problems adding tons and tons of extensions in other cases, just not this one. They have a problem with safety and security, not language extensions or dialects. None of it surprises me though. It's what I expect so I don't participate or even report bugs.