On 2/1/19 7:01 AM, Marek Polacek wrote: > 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. I disagree strongly. If we move it to Wextra it's going to see a lot less usage in real world codebases and potentially lead to the re-introduction of a class of bugs that we've largely helped stomp out.
It's also the case that maybe uninitialized vs is uninitialized is really just a function of CFG shape. Give me any "maybe uninitialized" case and I can turn it into a "is uninitialized" with simple block duplication of the forms done by jump threading, path isolation, superblock formation, etc. > >>> 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. Generally agreed in released versions of any code. -Werror *may* be appropriate in development versions depending on the project's policies, procedures and quality of codebase. Jeff
