Re: [PATCH] Kbuild: Move -Wmaybe-uninitialized to W=1

[Paul Bolle <pebolle@tiscali.nl>]

On Mon, 2014-07-07 at 12:53 +0200, Borislav Petkov wrote:
> This warning is enabled by -Wall or -Wextra, says the gcc manpage. It
> also says that gcc cannot always know whether the warning is issued
> correctly:
> 
> "These warnings are made optional because GCC is not smart enough to see
> all the reasons why the code might be correct in spite of appearing to
> have an error."
> 
> And, as expected, it fires for perfectly valid use cases, thus making it
> not really useful. Let's move it to the W=1 bunch in case people want to
> enable it with the additional checks.
> 
> Signed-off-by: Borislav Petkov <bp@suse.de>

Is the fact that this generates false positives by itself enough to
downgrade this check to W=1?

I do not have any hard numbers to back up my claims, but I'd like to
point out that it is possible that we never see many of the warnings
that GCC correctly issues because they might only occur during local
development. Ie, the developer involved cleans up the patch before
sending out.

My experience with the warnings that actually do make it into mainline
is that quite a few are correct while the false positives tend to be
generated by a pieces of code that are complicated (I think I've seen
the warning labeled as a "code smell").

For example, in my local builds this warning popped up three times in
the current development cycle:
    0) fs/direct-io.c:1011:12: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
       fs/direct-io.c:1011:12: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    1) drivers/platform/x86/eeepc-laptop.c:279:10: warning: ‘value’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    2) drivers/usb/misc/usb3503.c:195:11: warning: ‘err’ may be used uninitialized in this function [-Wmaybe-uninitialized]

Warning 0) occurs in a 150 line function, that grows over 200 lines when
the inline functions it calls are included. And I do think it's not easy
to see hwat that code does. Anyhow, see
https://lkml.org/lkml/2014/7/1/496 for my attempt to silence this
warning by simplifying this function.

See https://lkml.org/lkml/2014/7/1/150 for my patch that silences 1) by,
again, simplifying the code.

And warning 2) is correct. See https://lkml.org/lkml/2014/6/2/511 for a
possible solution.

So, in summary, I believe that the signal/noise ratio actually isn't too
bad. Moreover I think that the noise isn't merely noise, as it points to
possibly problematic sections of code.


Paul Bolle