This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: pointer <-> integer conversion warnings (bogus -Wall warnings )
On 14-Mar-2002, Tom Lord <lord@emf.net> wrote:
> Let's suppose that the value being converted back and forth between
> the two variables is not an address, but a range-limited integer.
Yes, in that case the usage is reasonable.
But the warning can easily be suppressed in that case using a double-cast.
> 4. There are all kinds of correctness analyses that can be
> performed on C programs that go far beyond what you'd
> expect a C compiler to do. Some of these are strong enough
> to only find bugs; some of these will only find code that
> should be carefully reviewed. Such analyses are so
> open-ended, imprecise, and unrelated to compilation, that a
> good strategy is to package them in tools like `lint'.
> You might even add extra annotation to your program to help
> lint-like tools be more accurate. Three levels of
> meaning for "this is clean code" are:
>
> a. it compiles
> b. it compiles with all the usual warnings
> enabled, without generating any warnings
> c. it passes inspection by <your favorite lint tools>
>
> Now, with the
> pointer<->integer conversion warnings enabled by default and by
> '-Wall', level (b) is gone.
If you think `-Wall' is supposed to mean your level (b), then I think
your are wrong. The documentation for -Wall says
| `-Wall'
| All of the above `-W' options combined. This enables all the
| warnings about constructions that some users consider
| questionable, and that are easy to avoid (or modify to prevent the
| warning), even in conjunction with macros.
The warning in question is definitely about a construct that
"some users consider questionable", and it is easy to avoid,
even in conjunction with macros, by using a double cast.
> When I first wrote this message, I said:
>
> Correct use of the double cast trick is only available to code
> that wants to rely on `intptr_t'.
No. See the code I posted, which doesn't rely on the existing of intptr_t.
> but thinking further about it, the double cast trick isn't even
> guaranteed to work in the presence of `intptr_t' since aren't we
> only guaranteed that `intptr_t' is large enough -- not that it isn't
> too large? (That's not a rhetorical question: I don't have a C99 spec.)
Yes, according to C99, intptr_t might be larger than a pointer.
But code using the double-cast trick will still work in that case.
It just might get a spurious warning. If that ever becomes a problem,
we can modify gcc to disable the warning on those platforms which
have intptr_t larger than a pointer.
> Support for levels (a) and (b) of the three levels of clean code
> listed above is something I consider to be an essential property of a
> real C compiler: a conceptually simple entity that is easy for
> programmers to control and that has a natural relationship to the
> language, sometimes augmented with fancy optimizations and combined
> (in tasteful ways) with features from tools like `lint'.
In that case, make patches for adding options to support level (b).
But I don't think it would be a good idea to change the meaning of
`-Wall' to try to implement your level (b), since `-Wall' already
has an long-standing meaning, and it is the meaning that many of
us want.
> Trying to
> force me to change public interfaces to perfectly reasonable
> libraries,
No one is asking that.
> switch to C99 at too early a date,
This is not necessary.
You can define your own intptr_t-like type without switching to C99,
using autoconf or #ifdef.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.