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

[Bernard Dautrevaux <Dautrevaux at microprocess dot com>]

> -----Original Message-----
> From: Tom Lord [mailto:lord@emf.net]
> Sent: Thursday, March 14, 2002 3:53 AM
> To: rth@redhat.com
> Cc: gcc@gcc.gnu.org; dewar@gnat.com
> Subject: Re: pointer <-> integer conversion warnings (bogus -Wall
> warnings)
> 
> 
> 
> 
>    From: Richard Henderson <rth@redhat.com>
>    On Wed, Mar 13, 2002 at 04:25:51PM -0800, Tom Lord wrote:
>    >	x = (int)(size_t) p;
>    > 
>    > That double cast is not safe.
> 
>    Care to explain your reasoning?  
> 
> I'm sure we can all figure it out.
> 
>    Care to point to a system for which it fails?
> 
> The one released in 2008 that has 64 bit pointers and integers with 32
> bit size_t.
> 

Don't go for 2008: just try to use a ix86 (x >= 3) in segmented mode:
pointers are 48 bits (segment + offset) while both size_t and ptrdiff_t
(that were not proposed but could have been) are 32 bits as no object can be
bigger than a 4Gb segment.

However for such a system I don't think "x = (int)p" could have ANY useful
meaning which will NOT loss some importabnt daat needed to be able to
successfully do "p = (void*)x" later; you will need some
compiler-and-architecture dependednt extension to piece a pointer in it's
segment/offset parts and build a new pointer from these parts.

The key point here is that *by definition* pointer/integer conversions have
*no* implementation-independant meaning, so they are inherently *non
portable*. I think shutting off the warning by using "intptr_t" in a double
cast is TheRightThing(tm). It is almost as portable, it's semantic is clear,
and if the compiler does not propose an "intptr_t" type, then either you can
easily add it (for example using autoconf tests, or in one of your
application header files) or you just can't because there is no such beast
and in this case you WILL have to correct your code, so I woudl advise the
compiler writer to even generate an ERROR in this case, not a warning, but
please don't flame me for that, it's not a request for a compiler change:-).

> 
>    > The simple rule that explicit casts to appropriate types don't
>    > generate warnings in the absense of extraordinary 
> options gives this
>    > class of warnings a clear and useful relation to the various
>    > standards.  I don't understand why that rule is at all 
> controversial.

Because a lot of compilers will just warn you of ALL implicit
pointer/integer conversions, so if you want to write portable code (I think
you were) you have to place explicit casts there... So only the double cast
could be used to silent the "differing-sizes" warning.

> 
>    Because virtually all code that pointer to integer casts 
> with "int" 
>    breaks on 64-bit targets.  This is not speculation; this is hard
>    experience bringing alpha-linux up from the first shell prompt.
> 
>    The warning isn't going to change.  It is going to remain enabled
>    with no -W flags whatsoever.  Live with it.
> 
> To match your tone I guess I'd have to make fun of you for confusing
> "virtually all code" with "alpha-linux" and express my shock that a C
> compiler maintainer would have such a sloppy attitude.  

I think I remember from my college years that a single counter-example was
sufficient to prove that an assertion was false, and that was the objective
of Richard (recusing your assertion that a single cast is enough and that
change in sizes can be ignored in case of an explicit cast) :-) 

> I really
> didn't want this to be a stupid mutual insult war, though.  Really.  I
> had this foolish idea that the GCC maintainers might want to find ways
> to balance the classical beauty and specificity of C with the
> pragmatic needs of the poor sods that have to do things like port
> Linux to alpha.

Alpha was an example where sizeof(int) != sizeof(void*). You own point
against using size_t in a double cast was that there may be architectures
where sizeof(size_t) != sizeof(void*), which I agree also and even give you
an example that is not in the far future...

> 
> It would be perfectly reasonable, as I've said repeatedly, to have an
> option that generates the warnings you want.  It would be reasonable
> to encourage Linux and Linux app developers to use that option
> regularly.  It would be reasonable to work on the problem at the right
> level: by improving the kind of testing infrastructure that exists for
> Linux and Linux app developers.  
> 

I don't think there is anything Linux-specific. We're talking of *portable*
ways to silent an useful warning.

> On the other hand, heck, _why_not_ just make GCC less of a real C
> compiler in _just_one_more_ way.  Who cares?  What difference does it
> make, _really_?  Especially if it means _rth_wins_!

Don't follow you there. I think the efforts of *all* GCC developpers is to
make GCC a *more* real C compiler, not a less one, and to solve all the
cases where it is not :-) And BTW I care! I've lost too many days in
debugging small errors that should have generated warnings if the compilers
I used then (some years ago) had been smart enough to warn me that I was
losing daat in a conversion I was thinking was safe reading the code, like
"x = (int)p;" where it happens that x is a short but you have to go up 40
lines to notice it ;-(

Of course perhaps we don't have the same idea of what a real C compiler is;
for me it's a compiler that hepls me writing *good* code and avoiding
dangerous constructs.

Just my .02euros,

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
--------------------------------------------