Conversation

Replying to

and

Often, uninitialized data usage actually ends up reading junk data from some register and programs can end up relying on the contents of that too, which will often be zero in practice. Real software often depends on reading uninitialized data and sometimes expects it to be zero.

2

Replying to

and

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.

1

1

Replying to

and

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

Replying to

and

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

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

11:59 PM · Apr 27, 2020Twitter Web App

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

Show replies