This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]