This is the mail archive of the
mailing list for the GCC project.
Re: handling of warnings
On Wed, 2003-08-13 at 22:13, Gabriel Dos Reis wrote:
> skaller <firstname.lastname@example.org> writes:
> Ignoring or not ignoring a flag not understood is not a matter of
> theorem proving.
please don't quote me out of context again.
You have changed the argument twice now and I'm afraid I missed
the first change you made.
First: I am talking about warning control options only,
though as noted the same argument applies to optimisations
I'm not talking about options in general as your arguments
here seem to imply.
Secondly I didn't say ignoring or not ignoring a flag
is a matter of proving a theorem, I said it can be proved
that it is necessary to ignore the flag (or issue a warning)
IF you assume the set of warning options ought to be volatile
(or words to that effect).
> | 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.
> Not just because you can't use it with 3.2.2 means it is useless in
Sigh. I can't use the flag. Worse than that, I have to suppress
a particular warning, so I have to use -w to turn them ALL off.
Please note: I do NOT mean I can't use it because I only
have 3.2.2 and not the latest compiler. I can't use it because
the handling of unknown warning control options is BUGGED:
my clients could be using ANY recent variant of g++ and so I can't use
any new options or they won't be able to compile the code.
I am quite happy to generate ISO C++ code where possible,
and require an ISO C++ compliant compiler. It happens unfortunately,
that there are two non-standard features I have to use: long long
and offsetof into a non-POD.
The first issue is a normal upgrade problem: C++ hasn't adopted
long long yet, but I require 64bit integers anyhow.
The second is a deficiency in the ISO Standard. I need a workaround,
and I do not want that workaround to cause either an error or
a warning. It isn't an error, I'm deliberately relying on
an extension. I do not need a warning, I know I'm doing it.
So I need to turn the warning OFF. But I can't, other than by
using -w to turn all warnings off, because I don't know which
gcc variant the client is using, i don't WANT to know,
and I shouldn't need to know.
SO the logic is: I have no option than to turn ALL warnings
off because of the current behaviour of g++ 2.96, 3.2.2,
and, from what you are saying, the current development version.
I consider that very bad, I want to have all warnings enabled
except for a few, where I know I'm generating code that might
trigger a warning. I hope you'll agree that is a reasonable desire.
Well, if gcc ignored unknown warning control switches,
I'd just set all the warning switches on, based on the union
of all possible switches for all known versions of the compiler.
No problem if the compiler doesn't issue a particular warning,
some diagnostic capability is lost.
So I have to regard the current behaviour as a design fault.
There is a superior alternative to the current design.
The only downside is, as you have said, a spelling mistake
or other wrong warning control option would lead to either
NOT suppressing a warning -- which is very easy for the client
to notice and so can't be regarded as a major issue --
or failing to issue a particular warning.
The last point is the most serious consequence, and I would agree
loss of detection of possble coding error without knowing
that one failed to actually enable the detection, is nasty.
But it is no where *near* as nasty, in my opinion,
as not being able to use the warning switches at all.
And that's the position everyone is in if they don't know
exactly which version of gcc they're using, and that is
likely to be almost *every* C/C++ software developer.
[Other than gcc hackers :=]
> | 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.
> Can you elaborate on this?
Well, in 2.96, you can't use a long long in C++ when you
have strictness on (-ansi -pedantic).
Long long wasn't part of ISO C90(C89), nor ISO C++.
But it is part of ISO C99(9X). But not yet C++.
So if you want to be pedantic about standards compliance,
which I like to be where possible, but you also want to
allow long long as an extension, you need to say something like
-D_GNU_SOURCE -Wno-long-long -ansi -pendantic
in 2.96. In 3.2.2 I have found you don't need -D_GNU_SOURCE
whatever that was (probably a mistake to remove it so
the code still compiles on 2.96 though :(
Now, it is likely that ISO C++2099 <g> will have long long,
and it is possible that the warning -Wno-long-long will then
be removed. In which case my build will break, since I'm
specifying that switch.
My point is: it is desirable *in my opinion* to allow a rich
and fairly unstable set of warning (and optimisation) control
switched, and the only way to handle that transparently
is not to error out the compiler when a warning control
(or optimisation control) switch isn't understood.
Perhaps I can put this another way: gcc would be a much
better tool if a large set of diagnostics were available,
together with fine grained control over them. Without that
control, one has to be very careful about issuing incorrect
warnings. For example consider:
int x = x + 1;
Now, a brain dead warning:
'initialisation of variable "x" depends on itself'
is possible if, and only if, I can not only suppress that
warning in deliberate cases of self reference
"thanks for the warning but I know what I'm doing"
not only for gcc versions that provide the warning,
but ALSO for prior versions that don't. Indeed,
later version might have a SMART warning:
"initialisation of variable x depends on its own value"
which isn't issued for either
void *p = (void*)&p;
unsigned char x = x - x;
even though the first warning is. I might well want to turn
that smart warning on .. even if I don't have a compiler
that can issue it.
In other words: breaking the build because of unrecognized
warning options can only be responded to by only using
stable and robust warning options .. such as -w or -Wall,
and living with the consequences .. defeating the purpose
of a quality set of warning diagnostic algorithms.
Same applies to optimisations, though the issue there
are more complex I think.