-Wall and all that

[kaih at khms dot westfalen dot de (Kai Henningsen)]

I thought I might as well offer my EUR 0.02 on this from a user  
perspective. Plus, it might make sense to look at the whole picture  
instead of arguing about specific details - one of the current problems  
seems to be that the definition for -Wall is rather fuzzy. A little more  
design might come in useful here.

I'll describe what, to me, would seem a pretty much ideal handling of  
warnings. (Some of this also applies to errors.) You know better than I  
how much work it would be to implement something like this, of course.


1. Define an identifier for each warning message. You could, of course,  
use the full text, but that'd be awkward to handle. Maybe something based  
on the relevant -Wxxx option would be sensible; commercial vendors seem to  
usually just use a number. Display this identifier which each warning  
message. (This might also be useful for the test suite. It's certainly  
useful with I18N.)

2. In the documentation, list these identifiers, related messages and
-Wxxx options. Where it is not painfully obvious, explain the problem.  
Explain what source change(s) would remove the warning. (For example, it  
took me quite a while to understand at least approximately when I would  
get a "may be clobbered" warning, and find a way to avoid it (and I'm not  
really happy with what I found).)

3. If the identifiers are more finegrained than the traditional -Wxxx  
options, have new options using the identifiers (maybe -Wid=yyy and -Wno- 
id=yyy to turn them on and off). If they're not more finegrained, that's  
not necessary, of course.

4. Have pragmas to turn them on and off locally, say _Pragma("GCC warn yyy  
on") and _Pragma("GCC warn yyy off").

5. Define some warning groups. Define precisely what qualifies a warning  
for each group. Some possible examples:

  -Wcommon-errors  Constructs that often are used mistakenly, and where
                   their use is not a mistake, can be written in a
                   (documented) way that will silence the warning. Say,
                   missing prototypes, assignments where conditions are
                   expected, stuff like that. (Some claim that this is the
                   traditional definition of -Wall.)

  -Wstyle-warnings Warnings that reflect not following some particular
                   coding style, nothing that is objectively wrong

  -Wportability    Stuff that might break with another CPU or another
                   compiler

  -Wobscure        Warnings about more exotic problems (that is, problems
                   that are unlikely in typical code), possibly such that
                   the only way to quiet the warning is to use the pragma

  (I'll note that both -Wall and -W are rather badly named.)

6. I don't like writing docs either, but good docs in this area are worth  
a lot, so I'll repeat this point. Warnings or warning options are only  
useful if people understand them.

MfG Kai