Re: pointer <-> integer conversion warnings (bogus -Wall warnings)

[Tim Hollebeek <tim at hollebeek dot com>]

On Wed, Mar 13, 2002 at 02:57:54PM -0800, Tom Lord wrote:
> 
>    Date: Wed, 13 Mar 2002 17:49:16 -0500
>    From: Tim Hollebeek <tim@hollebeek.com>
> 
> 
>    > There is no integer type guaranteed to be wide enough to hold values
>    > from pointers.  So unlike the first warning I asked about, I don't see
>    > any reasonable "double cast" that solves the problem.
> 
>    Why not:
> 
> 	 x = (int)(intptr_t)p;
> 
> 
> Because it is certainly not portable and is not as nearly as I can
> tell, part of ISO/IEC 9899:1990 or IEEE 1003.1-1990.
> 
> A good heursitic for portable code is when there is agreement (on the
> topics they all cover) between:
> 
> 	"The Standard C Library" (Plauger 1992)
> 	"Posix Programmer's Guide" (Lewin 1991-1994)
> 	"C, A Reference Manual" (Harbison & Steele, fourth edition, 1995)
> 
> The last book, in particular, observes "Some computers may have
> pointer representations that are longer than the largest integer
> type" and I'm inclined to go with that.

This thread is about shutting up warnings, when p is *known* to be a
pointer for which the above is safe.

By your rule, all cast from a (potentially) wider type to a smaller
type deserve a warning.  By that rule, this warning, and hundreds of
other false positives like it, are unavoidable.  Practical experience,
however, shows that most pointer abuse comes from cases between
pointers and smaller sized integral types.

Because of this, reasonable compilers (like gcc) turn a blind eye to
such things as (short)(long)[int], or at least consider them to be far
less egregious than (int)[char *].

The ptr <--> int boundary is far more likely to indicate an
unwarranted assumption than the conversion between integral types of
different sizes, and the valid conversions between integral types of
different sizes occur far too often in reasonable code to generate
warnings.

Let's face it, *any* conversion between pointers and integers
*already* invoked implementation defined behavior.  Arguments that
further operations may loose precision (oh my!) simply indicate the
author is in pedantic language lawyer mode and has not weighed the
usefulness of various constructs against the guarantees on their
behavior provided by relevant standards.

Please be familiar with this material before quoting basic references
at me.

-Tim