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.