This is the mail archive of the
mailing list for the GCC project.
Re: handling of warnings
- From: Andrew Pinski <pinskia at physics dot uc dot edu>
- To: skaller at ozemail dot com dot au
- Cc: Andrew Pinski <pinskia at physics dot uc dot edu>, Gabriel Dos Reis <gdr at integrable-solutions dot net>, gcc mailing list <gcc at gcc dot gnu dot org>
- Date: Wed, 13 Aug 2003 07:18:54 -0400
- Subject: Re: handling of warnings
On Wednesday, Aug 13, 2003, at 07:12 US/Eastern, skaller wrote:
I do not agree.Ignoring it, or issuing a warning,
is not only appropriate but it is easy to *prove*
it is the correct thing to do given that the set
of warnings controls should be able to be
changed easily from version to version of the compiler.
As it stands, the -Wno-invalid-offsetof is a totally
useless option, because it doesn't work on version 3.2.2,
and therefore I can't use it because I can't demand
my clients have the latest compiler.
Since the warning itself is unacceptable I have no choice
but to use the stable -w option to turn all warnings off.
Issuing an error when a warning control option is not
recognised is a BUG in gcc. It should be fixed.
The current behaviour renders the warning switches
next to useless.
This is not the only switch affected. Another example is
-Wno-long-long, which has to be switched on to allow
a long long to be used in ISO C++, in a manner similar
to C9X. Of course it will almost certainly be that
the C++ committee adopts this type into C++. Will the switch
then be dispensed with because it isn't appropriate
for *that* version of the compiler? Will it break
my scripts using -Wno-long-long by giving an error?
You could something like autoconf (or write you own configure program)
to find out if the warnings exist in your customers computers.
Every other compilers, ICC, Portland's, I know errors out on unknown