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: Friday, March 15, 2002 6:37 AM
> To: fjh@cs.mu.OZ.AU
> Cc: gcc@gcc.gnu.org
> Subject: Re: pointer <-> integer conversion warnings (bogus -Wall
> warnings )
	<skipped>

> 
> An explicit cast, though, expresses the programmer's intention to
> invoke a potentially dangerous conversion.  Except in the presence of
> an option like `-Wcommon-mistakes' or `-Wcheck-for-possible-idiocy',
> no warning should be generated.
> 

I can agree with that; BUT for the problem we are interested in there is TWO
warnings to silent: one for implicit pointer->integer conversion, one for
loss of accuracy.

We need a way to silent one or the other at will. Casting to the final type
will silent any loss of accuracy warning; casting to a large-enough pointer
type will silent the pointer->integer warning. 

Thus the double cast which perfectly fit your criterium.

For integer->pointer conversions we have the same mechanism, except we need
a integral type that is exactly the same size as the pointer type. Thus on
an architecture where there is no such integral type (like the i386 in
segmented mode where integral types are 32 or 64 bits and pointers 48) I
will admit that an explicit cast from an integral type of the smaller size
greater than the size of a pointer MUST silent the warning. 

> 
> 	2. One intention of the default conversion in the language is
> 	   that, for a small enough, not necesarilly 0 integer, the
> 	   round trip will give the same integer.  It's hard to
> 	   imagine any implementation that won't, in fact, get this
> 	   "right", treating:
> 
> 			p = (void *)x;
> 
> 	   as equivalent to:
> 
> 			p = (void *)((char *)0 + x);
> 
> 	   and
> 
> 			x = (int)p;
> 
> 	   as equivalent to:
> 
> 			x = (int)((char *)p - (char *)0);

This is plain wrong!

The problem there is that (char*)p - (char*)0 is EXPLICITELY defined as
undefined behaviour by the C standard: pointer arithmetic is only allowed if
the two pointers point at the same "object"... 

Note that for example on a segmented i386 the above set of transforms may
not be reversible at all: the segment part of ((char *)0 + x) will surely be
the one for (char*)0, probably 0, but the offset could be constrained (even
possibly by the hardware) to the size of the segment, that is forced also to
0! 

Conversely the pointer difference could be forced to some illegal value (or
even raise a hardware exception) as the result has no meaning at all. After
all how many characters are there between p and nothing? that's like the old
french joke: 
	"Do you know the difference between a duck?" 
	"There's no, both legs have the same length, especially the left!"

Thus the "justification" you give for saying that it's _useful_and_portable_
to convert between pointer and integral types of differing types is flawed.
It IS undefined so the compiler MUST warn and there is no problem if there
is no "portable" way to silent it, especially if the cases where you don't
silent it are those where the semantics is effectively undefined! :-)

Best regards,

	Bernard

PS: and no, I'm not affiliated with any of the companies that may be "over"
represented in the SC, but just like th eidea that whenever I code something
potentially dangerous, I get warned by the compiler; as long as I can silent
that I'm happy, and like the idea the silenting is not a "once and forever"
but may be breaked if the architecture I compile for is a bit more exotic
than I have expected...

--------------------------------------------
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
--------------------------------------------