Conversation

Replying to

and

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

Replying to

and

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

Replying to

and

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

Replying to

and

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

Replying to

and

... language dialect. Do you disagree with anything in that claim?

1

Replying to

and

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

Replying to

and

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

Replying to

and

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

Replying to

and

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

Replying to

and

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

Replying to

and

.. want that to justify having it upstream too, why not? I personally don't care. They have thousands of extensions to C and C++ already, many of which are hardly used. A switch for zero-on-init semantics would be a different thing and I wouldn't see any issue with having that.

12:11 AM · Apr 28, 2020Twitter Web App

Replying to

and

The only thing that's relevant is if they want to commit to maintaining the code for it. In this case, it's hard to see why it would be a problem, especially since the code generation support is already there, just not disabling warnings, etc. and defining it as not being wrong.

1

Replying to

and

I personally want strict uninitialized variable checks with zero-on-init as a code generation strategy for legacy code not conforming to it. I don't intend to force my subjective opinions on people like them. People should be free to not have either of these things...