This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Should -Wmaybe-uninitialized be included in -Wall?
- From: Andreas Arnez <arnez at linux dot vnet dot ibm dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Andrew Haley <aph at redhat dot com>, gcc at gcc dot gnu dot org
- Date: Wed, 10 Jul 2013 12:51:01 +0200
- Subject: Re: Should -Wmaybe-uninitialized be included in -Wall?
- References: <87ehb8rljz dot fsf at br87z6lw dot de dot ibm dot com> <51DBFC32 dot 8050401 at redhat dot com> <87siznrg4y dot fsf at br87z6lw dot de dot ibm dot com> <51DC872C dot 7030303 at redhat dot com>
Jeff Law <law@redhat.com> writes:
> On 07/09/2013 07:56 AM, Andreas Arnez wrote:
>> Andrew Haley <aph@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.