On 07/10/2013 04:51 AM, Andreas Arnez wrote:
Jeff Law <l...@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
