Re: Should -Wjump-misses-init be in -Wall?

[Robert Dewar <dewar at adacore dot com>]

Jeff Law wrote:

> While I agree with most of what you said Robert, reality is I have run 
> into long time GCC users with extremely large codebases who use -Wall 
> -Werror and go ballistic any time new warnings are added (the process to 
> get even trivial fixes into their codebase is, umm, lengthy to put it 
> mildly).
>
>  I've argued with them on multiple occasions that using -Wall in this 
> manner was a bad idea and that choosing a set of -Wblah warnings to use 
> instead would save them lots of time and headaches, but the message 
> never sticks.

Well apparently the real message (more warnings that they don't like)
does stick :-)

The fact that these guys go ballistic does not really improve the
merit of their dubious argument.

They are using -Wall because they find compiler warnings useful.
After all they can always turn off -Wall if they want.

The ONLY legitimate and useful input from users is if a new
warning generates too many false positives (and indeed we want
to hear about ANY false positives, but see below for my
definition of false positive).
> I think (as always) we need to find a balance between throwing 
> everything *we* find valuable in -Wall and avoiding all changes to 
> accommodate users on the other end of the spectrum.  With that in mind 
> I'd ask Ian to chime in and say something about the # of warnings we 
> found in our own codebase vs how many of those warnings represented real 
> bugs vs false positives.

I am not sure "real bugs" vs "false positives" is the right 
categorization. There are really four cases:

1. Real bugs, such that a test program could be written to show the bug

2. Potential bugs, wrong C code that happens to work but might fail in
   a future version of the compiler which compiles things differently,
   or for example if an uninitialized variable has a different value.

3. Wrong code which for whatever reason cannot actually result in a
   mal-function, but which nevertheless should be fixed because it
   is not desirable.

4. Useful code that is being warned about

ONLY case 4 is a false positive to me. When we add new warnings
in GNAT, we find that very often the majority of new warnings
are in categories 2 and 3.

You definitely have to tolerate a fair number of case 2 and
case 3 situations, which in any case help clean up the code,
in order to find a smaller number of real bugs in case 1.

Of course if you find there are a significant number of case 4
real positives, you want to fix things. This has nothing to do
with backwards compatibility, it is just part of the general
effort to avoid false positives in warnings, since compilers
are generally in the business of making a good balance between
false negatives and false positives.
> Jeff