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