Messages in this thread | | | Date | Thu, 3 Mar 2016 15:04:59 +0100 | From | Ingo Molnar <> | Subject | Re: Q: why didn't GCC warn about this uninitialized variable? (was: Re: [PATCH] perf tests: initialize sa.sa_flags) |
| |
* Jakub Jelinek <jakub@redhat.com> wrote:
> On Thu, Mar 03, 2016 at 02:24:34PM +0100, Ingo Molnar wrote: > > 6 hours of PeterZ time translates to quite a bit of code restructuring overhead to > > eliminate false positive warnings... > > I'll file a bugzilla enhancement request for this (with new attribute), > perhaps we could do it in FRE that is able to see through memory > stores/loads even in addressable structures in some cases. > Though, certainly GCC 7 material.
> And, in this particular case it couldn't do anything anyway, because > the sigfillset call is not inlined, and takes address of a field in the > structure. The compiler can't know if it doesn't cast it back to struct > sigaction and initialize the other fields.
That's true - but I think in the typical case it's a pretty fragile pattern to go outside the bounds of a on-stack structure you get passed, so I wouldn't mind a (default-disabled) warning for it, even if it generates false positives that have to be annotated for the few cases where it's a legitimate technique.
I am 99% sure that a fair number of security critical projects would migrate to the usage of such a warning, combined with -Werror. I'm 100% sure that perf would migrate to it.
> BTW, valgrind should be able to detect this.
Yes - assuming the uninitialized value gets used. Often they are in rarely used code and error paths, only triggered by exploits.
It would be far better if GCC allowed a (non-default) C variant that makes it impossible to introduce uninitialized values via on-stack variables. The maintenance cost of the false positives is the price paid for that (very valuable) guarantee.
Thanks,
Ingo
| |