This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Wconversion versus Wcoercion
On 10 Jun 2006 20:07:02 -0500, Gabriel Dos Reis <gdr@cs.tamu.edu> wrote:
I'll like to see a more precise definition of your understanding of
"coercion" versus "conversion". Last time we dicussed this I was not
quite clear about what you consider is "bad" what is not.
I was under the impression you taught it was for "C" only, but you
have to take into account that some warnings are shared with the C++
front-end and some of them really should be common to both front-ends.
If your project is NOT about coercion in general, but those just
related to function prototypes, you should be careful about the name
of the option. Again, this assumes you tell us what you consider
coercion and what you consider conversion.
-- Gaby
My project is about "risky" coercions in general: assignments,
operators, prototypes. You can see some (and comment and propose)
testcases in http://gcc.gnu.org/wiki/Wcoercion . I haven't thought how
all this works when you include classes and objects and inheritance.
However, this doesn't matter for this discussion because just taking
into account the current code in trunk, there are several problems :
1) Following the documentation, currently Wconversion is used for two
different and unrelated things (i) "Warn if a prototype causes a type
conversion that is different from what would happen to the same
argument in the absence of a prototype" and (ii) "warn if a negative
integer constant expression is implicitly converted to an unsigned
type". These two behaviours should be split.
2) Currently, Wconversion works very different for C and for C++. I
have not seen anything in the manual explaining this, so I assume that
it is undocumented behaviour. I think this is bad: C and C++ should be
in sync and the current behaviour should be explained in the manual.
3) People using Wconversion to detect conversions that may be risky
are frequently told that this is not the intended purpose. However, in
g++, it currently works to some extent. People should not rely on
this. We should either warn them somehow that this is wrong or we
should fix Wconversion to do what they expect. However, fixing
Wconversion would silently break things for those that rely on its
original purpose.
So, I propose a third option:
c) Remove Wconversion and create two new options Wcoercion and
Wprototypes-traditional. The reason is that both options (a) and (b)
would silently break Wconversion for someone. And keeping Wconversion
is not an option since it is currently broken and we need a way to
warn people already using it in the wrong way. Also, keeping
Wconversion raises the issue of what to do with the undocumented
behaviour already implemented in g++. So the best option is just
remove Wconversion and let people know that they should use one of the
two new options. Of course this can be done in a very gradual way. For
example, Wconversion may call the new options and issue a warning
message.
Cheers,
Manuel.