Well I guess everyone everywhere will want to use -fzero-init-padding-bits=all when updating to GCC15 to avoid regressing their uninitialized variable mitigations... Why in the world would the C standard committee work to make things *less* safe by default??!
Edit: this appears to be a decision on GCC's part and not a new change from the C committee. (See down-thread.)
@kees It's a ploy by static analysis companies to sell you more checks....
@kees uh, wth. This is depended on all over the place.
@kees I do not know why GCC made this change, but it is *not* helpful to blame committee (that certainly failed to close this loophole) but also did not make it less safe relative to before. In fact, this is exactly the misdirection that lets compiler vendors get a away with this nonsense. (edit: note that I thought this is about {} not fully initialization but GCC gets this right, I am less critical about the {0} change)
@uecker This looked like it was GCC trying to follow the standard. Is that not accurate? Because that option ("the default setting is 'standard'") really seems to be saying so. Whatever the case, it's a regression in behavior.
@kees The standard does not require this new behavior and did not change in this regard. It seems to allow this because we somehow failed to close this loophole and it is disappointing to see that GCC did this change for optimization. (edit: note that I thought this is about {} not fully initialization but GCC gets this right, I am less critical about the {0} change)
@uecker What's going on with GCC claiming this is somehow related to C23? This is very confusing.
@kees The documentation link cites C23 empty initialization {} as an example and that is new, but { 0 } does the same.
@kees I even filed a bug for clang related to this (thinking we require full zero initialization): https://github.com/llvm/llvm-project/issues/78034
@uecker It's more than that, though. For example, see this bug, where C23 seems to be the rationale for the change:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118403
@kees It is indeed a bit different than I thought. The issue is that C23 introduced empty initialization with the requirement to initialize padding. This does not include bytes in unions of other members (the loophole) but it seems gcc / clang still clear those (as intended!). But GCC also (coincidentally) decided to optimize zero init { 0 } as already allowed previously (no change in the standard). (Edit: the {} was working also before, so the patch was just the optimization of { 0 })
@kees
better example:
https://godbolt.org/z/bnnxqozac
foo was optimized as would be allowed even before C23. foo2 uses C23 but this did not change.
@Aissen @uecker @kees it used to be required, `{}` was a gcc extension iirc (it even used to warn differently between clang and gcc, so whether you used `{}` or `{0}` one of the compilers would yell at you), so it's going to exist in both forms in lots of places. the problem is that some of those places are now going to be bugs. (but you're right that you probably should lose the habit and start using `{}` if your compiler support matrix allows it)
@kees The problem is that in the standard committee the vendors will always argue that what they do is what their customers want. So users blaming WG14 instead the compiler vendor responsible is weakening our power to fix it instead of helping.
@kees they didn't, GCC changed The way they comply
@kees They did send aail about this around or before Christmas about this to lkml btw.
@brauner @uecker @pinskia Yup, I saw that from the bug report (but missed it back in December). Here's a patch, with the selftest results:
https://lore.kernel.org/lkml/20250121003646.work.168-kees@kernel.org/
@kees @brauner @uecker @pinskia I filed https://gcc.gnu.org/PR118575 for maybe some better UX when interacting with -ftrivial-auto-var-init=zero
.
@thesamesam @kees @brauner @uecker @pinskia Okay, this might be me just being stupid here, but in "PR118575", does "PR" stand for "problem report" or something else?