On Fri, Feb 01, 2019 at 07:19:25AM -0600, Segher Boessenkool wrote:
> Hi Marc,
> 
> On Fri, Feb 01, 2019 at 12:32:45PM +0100, Marc Glisse wrote:
> > -Wmaybe-uninitialized generates false positives, we can tweak the compiler 
> > to reduce them, but there will always be some, that's in the nature of 
> > this warning.
> 
> That is true for *every* warning; if not, it should be an error, not a
> warning.
> 
> > My opinion is that -Wmaybe-uninitialized would serve its purpose better as 
> > part of -Wextra.
> 
> +1

+1 from me too.

> > People tend to use -Wall with -Werror (either explicitly 
> > or implicitly by modifying the code until all warnings are gone). What I 
> > see currently in projects where I participate is that 
> > -Wmaybe-uninitialized is making things worse. People don't investigate 
> > deeply the cause of the warning, they just go for whatever "quick-fix" 
> > makes the compiler shut up. Quite often, this involves extra code that is 
> > less readable and performs worse, while it didn't even "fix" what caused 
> > the warning, it just randomly ended up with code where the compiler 
> > doesn't warn (possibly because the function got bigger, which changed 
> > inlining decisions...).
> 
> Yes, using -Werror is usually a terrible idea.
> 
> > Note that similar arguments may apply to some other warnings that somehow 
> > made their way into -Wall when they shouldn't have, but for now I am only 
> > proposing to move -Wmaybe-uninitialized. Some people tend to consider that 
> > if a warning is not part of -Wall, it might as well not exist. Obviously I 
> > disagree with that.
> 
> If it is not part of -Wall and not of -W, and not special purpose, then it
> might as well not exist.

There are warnings that *do* make sense, but have issues e.g. with macro
expansion, so will be outside -Wall/-Wextra unless that's fixed.  E.g.
-Wlogical-op, -Wduplicated-conds, or a warning I posted to some PR
called -Wsame-arguments I think, etc.

Marek

Reply via email to