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

[Jeffrey A Law]

  In message < 199809071429.KAA21397@melange.gnu.org >you write:
  > >I believe this to be an over-statement.  For this particular
  > >situation, I think `#pragma' is the way to go.  If I do not hear
  > >violent disagreement in the next few days, I will go ahead and
  > >implement this.
  > 
  > I don't think offering a `#pragma' interface is a bad idea, but
  > at least one other interface should be considered.
Well, pragmas have been frowned upon for some time in the gcc world,
so that's a strike against them.

  > My other concerns about this are more general and over-arching:
  > 
  >   -  Without a class heirarchy and facility to enable/disable/push/pop
  >      warnings of an entire class, there are likely to be practical
  >      cases that require long, unwieldy lists of warnings to disable,
  >      especially once the attitude that "adding new warnings is always
  >      okay now that people can individually disable them in a chunk of
  >      code" has had time to establish itself.  (Look at all the
  >      discussions about adding arbitrary new attributes, or properties,
  >      to gcc/g++.)
Yup.

  >   -  As a result of adding this feature, source code will have a greater
  >      tendency to be changed with each new release of the compiler to
  >      accommodate the different warning "contour" of that release.  (A
  >      warning "contour" is the relationship of warnings to the source
  >      language, so whether a given warning occurs given a particular
  >      input contributes to a conceptual contour of all the warnings.)
Yup.  In fact, I'll go ahead and note that I would *discourage* us from
using such a facility extensively within the compiler itself.  At least
until all such reasonable avenues of fixing code has been explored.

I generally worry that in the effort to get to no warnings in a compile
that we'll end up making a whole lot more work for ourselves by adding
all these magic flags & markers in the source which we'll then have to
tweak far too often.


  >      E.g. compiling g77 produces spurious warnings on Alphas -- in the
  >      future, the temptation might be to modify g77 instead of fixing
  >      the compiler to no longer produce the spurious warnings.  (These
  >      are the uninitialized-variable warnings Jeff and others have
  >      said need to be fixed -- in gcc.)
Right.


  > Also, I think it's worth pointing out that the source code for the
  > compiler will become somewhat less readable, at least to people
  > like myself who can quickly scan code for diagnostic messages
  > displayed by it to get an idea of what it is doing.  Having architected
  > g77 in somewhat the same way, I've learned how to mitigate this
  > somewhat by using readable keywords to denote the messages, but
  > still find the need to cross-reference a common file to be
  > bothersome, even though I wrote all the original code.
Yes.  I've worked on software which used error #s and macros to
hid the actual number behind a contrived small name.  It was (and
still is) quite unpleasant.

  > For example, if there are advantages to internationalizing gcc
  > by doing this work, that seems worthwhile.  Maybe there's a better
  > way to do it, though.
Well, much of gcc2 got internationalized 4-6 weeks ago using a scheme
similar to the one found in binutils, gas, gdb, texinfo, etc etc.  We
should play well with the rest of the GNU world in this regard.

jeff