What about introducing a new blanket warning kind that excludes anything with false positives? something like -WALL ?
David On Wed, Jul 10, 2013 at 3:51 AM, Andreas Arnez <ar...@linux.vnet.ibm.com> wrote: > Jeff Law <l...@redhat.com> writes: > >> On 07/09/2013 07:56 AM, Andreas Arnez wrote: >>> Andrew Haley <a...@redhat.com> writes: >>> >>>> On 07/09/2013 12:59 PM, Andreas Arnez wrote: >>>>> With this situation at hand, I wonder whether it's a good idea to keep >>>>> maybe-uninitialized included in -Wall. Projects which have been using >>>>> "-Wall -Werror" successfully for many years are now forced to >>>>> investigate non-existing bugs in their code. >>>> >>>> But maybe-uninitialized is very useful, and it's not really inappropriate >>>> for -Wall. >>> >>> The warning would be extremely useful, if false positives didn't obscure >>> real problems. In its current state I consider its usefulness limited. >> Depends on your point of view. This topic has been hashed through >> repeatedly on this list. > > 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. > >> I personally like -Wall -Werror. While we do run into false positives >> and the set of false positives does change from release to release as >> a result of optimizations, I believe there's been an overall >> improvement in the quality of the codebases that use -Wall -Werror. > > Yes, I fully agree on the usefulness of -Wall -Werror and its > contribution to the code base quality increase. > >> I certainly see fewer bugs these days blamed on the compiler which are >> in fact uninitialized variables. > > 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. > >> 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. > >> What I would ask is that folks continue to file bugs for false >> positives. While I can't guarantee we'll fix them, they do provide a >> good base of tests for path sensitive analysis. > > Yes, I can see how the current policy of including this warning in -Wall > may help getting more coverage. > >> I'd also suggest that when an initialization is added merely to avoid >> the warning that a comment be added to the code so that folks know >> it's merely to avoid the warning. > > 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". > > OK, it appears that most people (silently or explicitly) accept the > inclusion of warnings with false positives in -Wall. I'm not hung up on > this. It would just be nice to reflect this appropriately in the > documentation. >