On Fri, Feb 01, 2019 at 12:27:57PM -0700, Jeff Law wrote:
> On 2/1/19 7:01 AM, Marek Polacek wrote:
> > On Fri, Feb 01, 2019 at 07:19:25AM -0600, Segher Boessenkool wrote:
> >> On Fri, Feb 01, 2019 at 12:32:45PM +0100, Marc Glisse wrote:
> >>> 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.
The usual workaround, especially for programs that build with multiple
(i.e. older) versions of GCC, is to initialise any such variable (to an
either or not useful value) early. This doesn't fix the actual problem
usually (which is that your control flow is too complex).
> 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.
Are you saying that -Wmaybe-uninitialized should be included in
-Wuninitialized, since it has no extra false positives? That wasn't true
at all historically: -Wuninitialized has false positives on paths that
cannot be executed because of function preconditions, but
-Wmaybe-uninitialized used to warn for things that can be locally proven to
never execute, like
if (a)
b = 42;
...
if (a)
f(b);
> >> 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.
IMO it is more useful it is much more useful if you make your build system
less noisy so that problems are more obvious, instead of breaking the build
for no reason all the time (see PR89162, etc. etc.)
Segher
