Re: Should -Wmaybe-uninitialized be included in -Wall?

[Jeff Law <law at redhat dot com>]

On 07/10/2013 04:51 AM, Andreas Arnez wrote:
> Jeff Law <law@redhat.com> writes:
>
> OK, I may be biased, because I have *only* seen false positives with
> this warning so far.  Others may have made better experience with it.
It's found numerous bugs across many projects.  The reduction in bug 
reports against GCC which turn out to be uninitialized variables in the 
user's code has dropped dramatically over the last decade (if only the 
same could be said for user malloc errors reported against glibc :(

What you're seeing may be an indication that most of the real bugs have 
been found & squashed and what remains may be mostly false positives.

When you run into false positives, are you creating bug reports for 
them?  That's the best way to keep things improving.  I certainly want 
to continue to see the precision of all maybe-foo warnings improve.

> That's good.  But there are still some known false positives with "maybe
> uninitialized".  If there weren't, then this option could go away and be
> covered by -Wuninitialized instead.
False positives for maybe-uninitialized uses are a fact of life without 
heroic analysis.   However, I continue to see opportunities to improve 
GCC's ability to identify and optimize away unexecutable paths through 
the CFG.   In my experience, identification and elimination of those 
paths consistently leads to better precision of maybe-foo style warnings.


> > I'd like to revamp how we do path isolation to eliminate more of the
> > false positives, but this warning is by its nature going to generate
> > false positives.
>
> Right, that's the point.  My understanding of -Wall (so far) was that it
> shouldn't include warnings with false positives.
No, that's not true at all.  -Wall is a set of warnings that the GCC 
developers have found useful over time and strive to avoid triggering in 
our own code.  We've also seen that -Wall maps reasonably well to 
problems other projects want to fix in their own code.

We certainly evaluate whether or not the warning generates too many 
false positives when we decide whether or not to include it in -Wall. 
However, we certainly allow warnings which generate false positives to 
be in -Wall.




> Adding a bogus initialization is usually not a reasonable response to
> this warning anyway.  For instance, consider cases where certain
> elements of an array (like in bug 57832) or of a large struct (like
> reported in bug 55288) are falsely claimed to "may be uninitialized".
> Also consider cases where -Wmaybe-uninitialized reported the wrong
> variable, like in bug 55985.  Besides, a bogus initialization would also
> obscure helpful warnings, like those emitted from "-Wuninitialized".
I'm well aware of these issues.  There was a great article on this topic 
that I've wanted to hunt down again and be able to reference from time 
to time, but haven't seen again.

The general idea of the article was these bogus initializations can in 
some cases result in longer term maintenance problems.  They claimed 
that the bogus initialization could hide real uninitialized uses as the 
nearby code was changed over time.  If the bogus initialized value 
wasn't chosen very carefully incorrect behaviour would result.  In many 
cases where was no safe value to use for the bogus initialization.

Jeff