Conversation

Replying to

and

Similarly, if zero-init is a dialect, so is trapping or zero-or-trap. These are all ways of defining an undefined behavior which the language leaves up to compilers to handle. The -ftrivial-auto-var-init=zero switch does NOT make it correct to use uninitialized data. Still a bug.

2

Replying to

and

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, [...].

1

2

Replying to

and

In this case, if it is still reported as a bug by those tools, it definitely smells less like a dialect.

1

1

Replying to

and

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

Replying to

and

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

Replying to

and

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

Replying to

and

... but no one is depending on stack protector for a correct program: it's just a layer of defence against incorrect ones.

1

Replying to

and

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

Replying to

and

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

Replying to

and

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

Replying to

and

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.

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

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

Show replies