This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: -Wall and all that


On 17 Mar 2002, Kai Henningsen wrote:

> 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.)

This idea was extensively discussed in September 1998; there was even a
patch by Mark Mitchell that was checked in for less than a day.  Reading
the previous discussion from egcs and egcs-patches is recommended.  There
was no consensus support for message identifiers.  gettext works fine for
i18n.

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

This can be done gettext-style, by giving a regexp or substring to match
against the untranslated version of the message (which needs some changes
to make the untranslated version of the whole message be available at any
point, but is less invasive than solutions involving unique identifiers).
A message discussing this idea is linked to from the beginners' projects
list.


The warnings could indeed do with better definition of what's in what
option, and what deserves separate options vs. multiple warnings with a
single option.  In particular -W is a mess (not being a union of other
options) and should be split into well-defined options for the separate
warnings it controls (like -Wall is a union of other options).

More documentation might be useful.  An index to diagnostics has been
discussed in the past (so that a user, seeing "missing white space after
number", can go to the discussion in the manual of the pitfalls of
preprocessing numbers).

Every warning message should have a testcase; often, many testcases.  If
e.g. splitting -W into clearly-defined options, take the opportunity to
add testcases for all the warnings involved.

-- 
Joseph S. Myers
jsm28@cam.ac.uk


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]