Re: Extra warning from gcc

[Donn Terry <donn at interix dot com>]

I also agree that warnings are bad (and have been treated rather
poorly by various organizations who are cavalier about such things;
principles have their price).  (One said organization is believed to
have paid, massively, for that attitude later.)

Anyway... the problem is that 99% of all warnings deserve to be 
fixed, but a few shouldn't be, for various reasons.  Often a
specific warning is one that should be fixed in most places, but
occasionally not.  Rather than a proliferation of command line
options, this strikes me as a place for either a pragma or a
language extension like __attribute__.  (I actually prefer pragma.)
That way, it becomes possible to say "this specific warning on the
next line is expected, ignore it", without suppressing other instances
of the same warning, even in the same file.  (And by using
an include file of "just always ignore this one" commands, debates
about which warning belongs in which class never need darken our
door again.)

Yes, I know, it steps into the space of "portability problems" in
that pragmas are inherently a problem.

There's also the problem of identifying the warnings specifically.
(They'd need to be numbered or named; that's a nuisance, but it also
makes making a "detailed description" file a lot easier.)

(Another alternative would be some sort of "on the side" database
that was used either at compile time or in a post process to suppress
the "permanent" warnings, as long as the issue of changing line
numbers could be addressed.)

A suggestion for somebody looking for a project; I still have a
long list of other contributions hanging fire.

Donn

P.S.  Something like:

#pragma nowarn <ID> [<count>]

<ID> is some unique identifier of a warning (even warnings with
identical text get different id's).  <count> is taken to be one
if absent.  Otherwise skip N instances (for runs).  By convention,
counts >10 or so are "prohibited", preferring a "very large" count,
followed by a 0 after the run is completed.  (The counter
is probably required in the case of multiple instances of the
same warning on the same line, unless the sematics are "on
exactly the next line".)

David Cogen wrote:
> 
> > Some folks agree, others disagree.  The value of warnings will always be
> > different from one developer to the next.  I don't like adding yet more
> > options for something like this.
> 
> "Some agree, others disagree."
> 
> That is exactly the point.
> 
> One of the reasons I have always vastly preferred gnu compilers over Sun's is
> the numerous warning switches.
> 
> I take warnings very seriously. I want lots of control over warnings. I need
> to be warned about stupid things, but need, for strange cases, to be able to
> disable warnings on a file-by-file basis.
> 
> I consider a program which compiles with even one warning to be broken, and
> will fix it so it doesn't warn. But not by -w which turns off lots of
> important warnings.
> 
> In other words, the more warning switches the better!
> 
> IMO.
> 
> -- DavidC

-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================