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

Jeffrey A Law law@cygnus.com
Wed Sep 9 05:52:00 GMT 1998

  In message < Pine.LNX.3.95.980908120925.9733D-100000@plum.dwd.interkom.pl >you write:
  > What if you worked for a company that required, as part of their coding
  > style, warningless compilation?
You explicitly select the warnings you decide are appropriate and
make your code avoid such warnings.

Anybody that uses -Wall blindly is bound to run into problems simply
because the warnings that the egcs project decides are useful for -Wall are
not necessarily those which everyone will consider useful for -Wall.

-Wall is a set of warnings that one particular group values, and to
the extent that you share the same values -Wall will be useful.  But
if your values are different, then depending on -Wall and requiring a
silent -Wall build is just going to cause you headaches.

And yes, in my day job, I do deal with customers that requirewarning-
less compilations out of gcc, as does Richard and everyone else in 
Cygnus that's involved in gcc/g++ work.

  > > By number is particularly odious.  One, now we've got to manage
  > > numbers.  Two, we've got to preserve numbers from revision to
  > > revision -- they've just been enshrined as part of the GNU C API. 
  > > 
  > > In all, it sounds like a maintenance nightmare.
  > I fail to see your point. What is so difficult in managing numbers or
  > preserving them from revision to revision? Sure, it requires more careful
  > thinking before adding or changing warnings, but this is an advantage.
  > Currently, some warnings are added "just like that", because the author
  > thought they are "cute", or that "nobody in their right sense would write
  > something like this". It is only when other people try to compile their
  > projects, often some legacy code, that they notice what a poor idea the
  > warning was.
First, we don't want #s.  Really we don't.  I've worked with such systems,
it sucks.

No, we do not just add warnings "just like that".  Just ask the folks
that have tried to get new warnings installed into the compiler!  I'm
very leery of adding more warnings, particularly those which trigger
false positives.  In fact, dealing with the implicitly defined structure
warning's false positives is on my todo list, but I haven't gotten to
it yet because of egcs-1.1 responsibilities.

  > Small, cryptic keywords are not an advantage to numbers, IMHO. With so
  > many warnings as in GCC, the keywords won't be small, that's for sure. I
  > strongly prefer numbers, they at least look neat. Sure, numbers are
  > obscure, but that can be turned into advantage: user's won't overuse the
  > feature if it's difficult to use.
Agreed.  Both numbers and small criptic keywords are bad for this kind
of stuff.  The message belongs in the source.  This is also compatible
with how GNU gettext works, which we will be using as part of the
effort to improve internationalization support in egcs.


More information about the Gcc mailing list