The -ftrivial-auto-var-init=zero switch does not disable warnings for uninitialized variable usage and does not stop sanitizers like MSan from catching it. It's still a bug. It doesn't permit doing something but rather makes it less unsafe like CFI, ASLR, stack canaries, [...].
Conversation
In this case, if it is still reported as a bug by those tools, it definitely smells less like a dialect.
1
1
Permitting uninitialized variable usage by defining variables to be zero initialized would be a separate discussion to have and isn't what this switch is doing. This is just a code generation change. Sure, people can disable the warnings and rely on it but not the only example.
1
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.
1
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.
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
Show replies