RE: -W* rules for engagement?

[Donn Terry <donnte at microsoft dot com>]

Let me add a little on the side of fixing all warnings (over time):
On a new port (or with a new compiler, or....) there is no way to
know whether any given warning is benign or not.  (Particularly
since there is no canonical list of "expected" warnings.)  To
do a port right, each and every warning should be inspected to assure
that it isn't significant on that particular port.  That's
an expensive proposition if there are any number of "too much trouble
to fix" warnings.

Also, if there are more than an easily memorized handful, the appearance
of a new warning (which has a very good chance of being significant)
due to a code change is much easier to miss.

If it were my world :-) ... warnings would be acceptable, but each warning
would require that in the source code there is a one page or longer
(minimum acceptable size) explanation of why the warning is present,
why it cannot be fixed, who made that decision, and a study of possible
alternatives and why they were discarded.  For the 1 warning in 100
that is easier to fix that way than to make a code change, it's probably
justified to spend that effort.  The rest would be fixed by code change
real quickly :-) .

To be more realistic: how about a goal that 5.1 has a minimum number
of warnings, and provide a periodic scorecard on how it's going.
(And maybe 1-line comments for the ones that are painful to fix any
other way, so at least folks reviewing warnings know what to expect.)

Donn

> -----Original Message-----
> From: Andrew Cagney [mailto:ac131313@cygnus.com]
> Sent: Thursday, May 18, 2000 2:02 AM
> To: GDB Patches
> Subject: -W* rules for engagement?
> 
> 
> (The obvious follow on from PARAMS :-)
> 
> How do people think we should attack this?  I'm talking both from a
> logistic point of view of how should it be done and a 
> philosophical view
> of position (w.r.t. warnings) should be taken.
> 
> I can think of two extreme viewpoints:
> 
> 	o	fixing warnings is a waste of time.
> 		we've better things to do and besides
> 		we don't make mistakes.  Go away.
> 
> 	o	GDB shall compile with
> 		  -Wall -Wa-few-extras -Werror
> 		and emit no warnings.  Drop
> 		everything and fix all warnings
> 		now.  Add something to CVS so that
> 		it doesn't accept code containing
> 		warnings.
> 
> The obvious flaw with the first (and yet highly convincing 
> argument) is
> that people do make mistakes.  A second and more significant 
> problem is
> that code that contains ``warnings'' is, to a new developer, in an
> unknown state - was that if assignment ``if (x = y)'' intentional?. 
> While not much of an problem in a small project with a single 
> developer,
> it is a very big issue with a large long lived project with many
> developers (such as GDB).  Being able to make a change to a 
> file knowing
> that before/after it should contain no warnings is a real confidence
> booster to a developer.  The reason I spent a significant 
> amount of time
> last year expunging key warnings was so that I could, with a certain
> degree of confidence, make sweeping (but mechanical) changes 
> across many
> files.
> 
> The second proposal just needs a reality check.  While some warning
> checks (e.g. -Wformat) have a relatively small over head and a very
> significant return others such as -Wunused-parameters (yes, 
> GCC 3.0 does
> accept it!), I would argue, are of marginal benefit.  In selecting
> warnings I think we need to be careful to choose those that avoid lots
> of false negatives.  Further, given the vaguarities of 
> operating systems
> it is also often the case that zero warnings are physically 
> impossible.
> 
> 
> So what then?  I'd like to suggest we pad out the current list of
> warnings:
> 
>   -Wimplicit -Wreturn-type -Wcomment -Wformat -Wparentheses
> -Wpointer-arith
> 
> with a few additional key warnings such as -Wuninitialized
> -Wmissing-prototypes (any others?) and then try to get these down to
> zero so that -Werror can be used on this contracted list.  
> Beyond that,
> people, can pursue things at their leisure.
> 
> How to approach this? I'm easy.  I am wary of fix warning a-thons and
> the like.  Often fixing a warning involves a careful re-examination of
> the code.  If someone wants to take it on, I'm again easy.
> 
> 	Andrew
>