It's not like-fwrapv, which disables signed integer overflow warnings and disables the signed-integer-overflow sanitizer. That's explicitly a language dialect, as are the thousands of extensions that Clang makes to the language. This option is more like -fstack-protector.
Conversation
I disagree a bit, because all the flags that terminate the program when something goes wrong are materially different from ones that turn UB into a consistent, useful behavior.
APIs and other abstractions are littered with cases where people came to depend on those behaviors...
1
... but no one is depending on stack protector for a correct program: it's just a layer of defence against incorrect ones.
1
In some implementations it adds a guaranteed NUL byte to the end of the stack frame and some programs crash if it's disabled since they've accidentally relied upon it to terminate their strings outside of defined behavior.
1
Similarly, programs accidentally rely upon the stack being initially zeroed, since in practice it is for the initial usage, including for secondary stacks. Implementations caring more about security won't reuse stacks so programs could accidentally rely more on stacks being zero.
1
That's one of the reasons that programs already rely on zero-on-init semantics. The initial call chain down the stack will have zeroed frames in practice. It only starts being non-zero once there are returns and it's reusing stack space that was already used previously.
1
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.
1
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?
What if I get a distribution like Debian that's happy to patch software to remove this stupid switch? If they aren't going to remove it themselves, that's what I'm going to do. They can't stop people from having the option available. I used to add the option to Clang myself.
1
It's broadly used already. They take the approach of codifying existing usage for everything else. They happily copy over all kinds of weird, obscure and badly designed features from GCC and MSVC++. In this case though it's a 'dialect' and has to have some kind of weird debate.
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
Show replies