Re: Suppressing specific compiler warnings

[Matt Austern <austern at apple dot com>]

On May 26, 2004, at 12:18 PM, Gabriel Dos Reis wrote:

> | > Numbers are for computers. Names for people. A generalization,
> | >     but I am opposed to numbering warning kinds, on the
> | >     grounds that numbers tend to be harder to remember. If you are
> | >     reading a makefile, and you see -Wno-1492, you have no clue 
> why,
> | >     but if you see -Wno-unused you know what is going on.
> |
> | I tend to agree.
>
> I strongly agree.

I agree that names are good.  I'd just like to distinguish between
the name of a warning and the text that gets printed out.  If I write
struct A {
  int x;
  int y;
  A() : y(2), x(3) { }
};
then (on at least one compiler version; in general the details vary 
from release to release) I will get:

foo.cc: In constructor `A::A()':
foo.cc:3: warning: `A::y' will be initialized after
foo.cc:2: warning:   `int A::x'

The name of this warning is not "`A::y' will be initialized after `int 
A::x'".  It is not even "%s will be initialized after %s".

My claim is that, as things stand now, warnings do not have names.  The 
characteristics that I claim names should have:
 - Names should be brief tags.  I claim that brevity and uniformity are 
more important than looking friendly as English text: maybe something 
like 'iafter' for this one, for example.
 - Names should be printed as part of the warning text.
 - Names should appear in the index of the documentation.  That way, a 
user who sees a warning message can look it up by name and get more 
detailed information on what it means.
 - Names should be used in command-line options and pragmas in a 
uniform way.  That way, a user who sees a warning message can 
immediately know how to enable and disable it.
 - Names should be stable from release to release, even if the text of 
the warning varies.

But as others have pointed out, this is all hypothetical until someone 
volunteers to do the work.

			--Matt