Re: Warnings in the C++ Front-End and GCC in General

[Jeffrey A Law <law at cygnus dot com>]

  In message <199809090604.XAA02853@smtp.earthlink.net>you write:
  > Right!  But, at present, there's no way to select which warnings you
  > want at the level of granularity that many people might desire.  And,
  > I don't think we want to add tons more -W<xxx> options, and all the
  > accompanying `if' statements to manage them.  In any case,
  > command-line options don't give you a way to say what warnings you
  > want for particular pieces of code.
And I would claim that any finer granularity beyond compilation unit
level is unnecessary and the gains are not enough to justify the long
term maintenance issues.

For those cases where we can not control warnings appropriately turn
on/off some warning we should go ahead and bite the bullet and add
a new flag.  Yes, even though I think gcc has too many flags already.


  >     Jeffrey> First, we don't want #s.  Really we don't.  I've worked
  >     Jeffrey> with such systems, it sucks.
  > 
  > Do you mean as a user, or as a developer of the system?  I agree that
  > numbers aren't ideal, and I'm happy to take suggestions for better
  > mechanisms.  But, I too have worked with such systems, in both
  > capacities and I've found that:
As a developer.    The user doesn't need to know or care about the
numbers.  In fact, GNU standards strongly discourage error #s.


  >   o As a devloper, if the warnings are together, in a single file,
  >     it's easy enough not to perturb things: only add to the end of the
  >     file, and never remove entries.  (You can stop referencing the 
  >     warning, you just can't pull it out of the file.)
But as a developer, most of the time I'm trying to find out where and
why a particular warning is generated.  I rarely need to change a warning
string itself.



  > Furthermore, using mnemonic names for the warnings would just add to
  > the internationalization problem we already have: "-Wno-sign-compare"
  > may be intuitive to you but probably isn't to some who doesn't speak
  > English.  Unfortunately, it doesn't make sense to translate
  > command-line options, or the arguments to #pragma's, __attribute__,
  > and so forth because we want the same source code to compile no matter
  > what language the person compiling it happens to speak.
Agreed, Internationalization of command line options and such is a can
of worms we should not open at ths time.


  > As I've mentioned before, my patch has absolutely no affect on the use
  > of gettext, except, IMO, to make it even easier to use, since the `_'s
  > don't have to go in all the source files, but only in one place.  In
  > fact, you don't even have to worry about forgetting the `_' when you
  > add a new message!  I realize now that I used bad wording in my
  > original message; I lead some people to believe that I was proposing
  > some alternate means of internationalization.  I was not.
Noted.  Regardless we are not going to make this change.  Sorry.

Doing so would make any future merges from gcc2 nearly impossible.  I
do not see that the benefits gained by such a change outweigh the
losses from being unable to bring in code from gcc2 in the future.

You are welcome to raise the reorganization of messages again in the
future if we ever stop gcc2 merges, or if you convince gcc2 to go with
your scheme, then we will follow in the interest of being able to merge
in changes from gcc2.

I briefly touched on this issue earlier, but I did not give it the
attention it deserved.  That omission was my fault.  Sorry.


jeff