This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: -Wconversion versus libstdc++
On 18/01/07, Gabriel Dos Reis <gdr@cs.tamu.edu> wrote:
On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote:
| On 18/01/07, Gabriel Dos Reis <gdr@cs.tamu.edu> wrote:
| > On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote:
| >
| > | Does that apply also to:
| > |
| > | unsigned int y = -10;
| >
| > Yes.
| >
|
| Then, why Wconversion has warned about it at least since
| http://gcc.gnu.org/onlinedocs/gcc-3.0.4/gcc_3.html#SEC11 ?
The description on the page there is:
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. This includes conversions of fixed point to floating
and vice versa, and conversions changing the width or signedness
of a fixed point argument except when the same as the default
promotion.
Also, warn if a negative integer constant expression is implicitly
converted to an unsigned type. For example, warn about the
assignment x = -1 if x is unsigned. But do not warn about explicit
casts like (unsigned) -1.
As the PR you noted, it wasn't part of C++.
You are wrong. The PR was about signed->unsigned for two variables. A
warning about negative constant converted to unsigned has always
existed in g++! I have it in g++ (GCC) 4.1.2 20060928 (prerelease)
(Ubuntu 4.1.1-13ubuntu5). I guess it is also in GCC 4.2. And it was
present in g++ before as "warning: initialization of negative value
`-0x000000001' to `unsigned int'". It was moved to Wconversion on
revision 105421, before that moment, it was an unconditional warning.
| And my favourite, Gabriel dos Reis willing to implement a warning for
^
Please use capital "D" if you must write my full name; thanks.
Sure.
| int->unsigned int for g++:
| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26167#c3
|
| :-) I hope you understand why I think the issue is not as clear to me
| as it seems to be for you.
You never re-evaluate based on data collected from experimenting with
applications out there?
Yes, I do. Actually, that is what we are doing right now... let's see
if we can get the best solution.
Look at the code at issue in libstdc++. What is wrong with it?
As noted by Joe, such constructs are now likely common place, as they
fall from STL-style view of sequences. You have to take that into
account.
What is wrong with it is that if the difference between the two
pointers is negative you could obtain an unexpected result when this
negative value is converted to unsigned. Can we detect that this
cannot happen or that it doesn't matter? Is there any distinctive case
where we can detect that it matters and we should warn?
Assigning negative values to unsigned types is a typical security
vulnerability, it doesn't matter if you do it in complement-2
arithmetic. The result is not what the programmer (who may be unaware
of the unsigned type because it is hidden behind a typedef) expected.
So some cases of sign->unsigned are worth warning. Can we detect
those?
| Finally, why libstdc++ is using Wconversion at all?
Please go and read the PR submitted by Gerald.
I read it and still don't get it. We know we should not warn about
system headers but we do and that is a known bug. So again, why is
libstdc++ using Wconversion at all?
That doesn't mean that this particular part of the warning should not
be disabled. It just means that I don't think that because some
combination of warnings enabled explicitly by the user triggers a
warning in libstdc++ headers, the warning is invalid. Try for example
"-Wunreachable-code". It seems a much better approach to fix the bug
about warning in system headers rather than systematically trying to
avoid warnings for any possible warning option in GCC.
But still, it is good to know this, so we can remove the noise from
Wconversion. I just don't want to cut too much for the wrong reason
;-)
One use of -Wconversion is to draw attention to
int x = 2.3; // warning: be careful, is this what you want?
// this is a potential bug as it is value altering.
That was not the case until very recently and it has never been
documented. Before that, a warning for double->int was emitted without
Wconversion (GCC 4.1 for example). As I said before, the warning for
unsigned int i = -1; was in g++ way before this and it was the only
documented thing that Wconversion did. So anyone enabling Wconversion
before GCC 4.2, did it to get the negative constant->unsigned warning
(or by mistake or ignorance, of course).
I suggest to move "int -> unsigned" into a separate category, out of
-Wconversion, if you must keep it.
We could do that. -Wconversion-sign ? We could move it also to
-Wsign-comparison (enabled by -Wall) which I guess was implemented
because someone found interesting to warn about comparison between
signed and unsigned despite all the false positives that it produces.
That won't silence the warnings in libstdc++ if you use
-Wconversion-sign, though, because we have a nasty bug of warning
about system headers in the first place, is anybody working on that?
Or we could keep it for negative constants, such as unsigned int x =
-1; as it has always been for years and years, and remove it (or move
it to Wconversion-sign) for variables with unknown values (unknown to
the front-end, that is, the rest of gcc may know its value such as in
{ int i = -1; unsigned int ui = i; } but front-ends are a bit limited
right now).
Or we could just remove it, if it is completely useless.
There are different alternatives and I am not against any of them,
just would like to choose the best.
In any case, I would like to hear the opinion of Joseph Myers on this.
And perhaps he can ask people interested on this warning to put
forward testcases where the warning might be interesting and that we
could clearly separate from the most common false positives.
I was going to ask him anyway once Wconversion were (mostly) in
mainline. But there is still one important patch pending review since
November:
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00799.html
Cheers,
Manuel.