Re: Should -Wmaybe-uninitialized be included in -Wall?

[Xinliang David Li <davidxl at google dot com>]

On Wed, Jul 10, 2013 at 1:20 PM, Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:
> On Wed, Jul 10, 2013 at 2:49 PM, Xinliang David Li <davidxl@google.com> wrote:
>> There are two fundamental problems:
>> 1) uninit warning has false positives.
>> 2) people disagree what is the expected behavior of -Wall.
>>
>> 1) can only be solved by improving the analysis.
>
> I think we should focus on this.  While we can't attain perfection
> here, there is room for improvement for the cases that
> actually matter.
>
>> The new option is a
>> reasonable way to solve 2), unless you think the only way to solve it
>> is to change the behavior of -Wall, or ask concerned user to
>> explicitly use -Wno-error=... or white list the warning options they
>> care.
>
> I do consider that -Wall should be 'reasonably' free of annoying false
> positives, and that should be fixed by improving the detection
> analysis, of by removing the switch from -Wall.  This is the
> recipe we've applied so far, and it usually works.  Of course,
> a workaround, while waiting for the improvement, is to list
> the diagnostics that are at fault in -Wno-error=.
>
> In general, I think we are too eager to add new switches, but
> we have no framework in place to test the coherence of the
> various switches we keep adding.  A key attractive aspect
> of -Wall is that one does not need to know the gazillion
> switches that are activated.  One can make a case that everyone
> should know all of them, but that I think it is misguided to
> require every user to know everything we put in -Wall.
>

This points to other ideas:
1) how about adding a helper switch to show what is included in Wall?
such as -Wall-print
2) how about making -Wall configurable -- a default config file is
looked at by the compiler, but user can change the config or use a
different config they like.

David



> -- Gaby