Lots of it remains zero for various reasons (align padding, space reserved for variables not used in that call, arrays padded to max size, explicit zero-on-init, etc.) so lots stays zeroed and programs manage to depend on uninit data being zero even when reusing stack space.
Conversation
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
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
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.
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
Show replies
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.
1
Show replies