This is the mail archive of the
mailing list for the GCC project.
Re: handling of warnings
skaller <email@example.com> writes:
| > | By default, if a warning
| > | control option is not recognized it should be ignored, or a warning
| > | produced.
| > There ought to be a way to tell users that an option is not
| > recognized. Just ignoring is not appropriate.
| 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.
Ignoring or not ignoring a flag not understood is not a matter of
theorem proving. It is matter of design and use.
You might find it suitable for your particular use to have the compiler
ignore flags it does not understand. Fine. But it does not scale.
In particular, if we silently ignore a flag we do not understand, how
can the user tell whether
(1) we understood the flag but wrongly reacted to his request, a.k.a
a bug in the compiler;
(2) we do not understand the flag
We have choosen to tell users when we can't understand a flag.
That is a design decision, so that users can differentiate (1) from (2).
| 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
| Issuing an error when a warning control option is not
| recognised is a BUG in gcc. It should be fixed.
No, it is not a bug. It is a design decision. We don't want to
mislead users into thinking that we understand flags when we don't.
| 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?