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


On 19-Mar-2002, Tom Lord <lord@emf.net> wrote:
> 
> So what we're left with is this: the pointer <-> integer conversions
> are legal (with casts), though their meaning is undefined.  When used
> for range-limited integers passed through a `void *' variable, they
> have a conventional meaning that is reliably provided on pretty much
> every system we can imagine: reasonable programs can use that
> conversion.  It's one of the core strengths of C that programmers have
> access to such features.
> 
> At the same time, people often use those same conversions to pass a
> _pointer_ value through an integer variable.  That too has no fixed
> meaning, but reasonable programs can use it on many systems we can
> imagine wanting to use -- assuming that the integer type is carefully
> chosen.  People often enough don't make sure the integer type is wide
> enough for this purpose that, for example, rth has had to deal with
> many such bugs doing an alpha port of Linux.
> 
> The current warnings in GCC make the pessimal assumption: that code
> which legally casts between pointer <-> integer is likely expecting to
> preserve all the bits in both directions.  If the types differ in
> size, it issues a warning

I agree with all of the above.

> and that warning can not be suppressed.

The warning can be suppressed, by adding another cast.

> (If you're going to have such a warning, why not make it platform
> independent so that the problems show up before rth has to deal with
> them?)

Because doing so, without introducing any false positives, is very difficult.
A pity, I agree, but there it is.

> A variety of double-cast workarounds have been suggested as the means
> to suppress the warning.  None of these really solves the problem: we
> can imagine (perhaps even find) systems on which the widest integer
> type that is not wider than a pointer is too small to hold our
> range-limited integers --

This comment suggests that you still don't understand the proposed
double-cast work-around properly.  The proposed double-cast work-around
does not require using a type which is "not wider than a pointer".
If there is no integer type which has the same size as pointers,
then the intermediate type used must be at least as large as the
original integer type, which might well be wider than a pointer.

> The double-cast trick won't suppress
> warnings and will perform an incorrect conversion on systems with:
> 
> 	type		sizeof(type)
> 
> 	short		2
> 	int		8
> 	long		8
> 	intptr_t	8
> 	void *		4

No, it won't perform an incorrect conversion on such systems.  On such
systems, the intermediate type used should be `intptr_t'.  For `void *p',
`(int) (intptr_t) p' will perform the same conversion as `(int) p'.
Likewise `(short) (intptr_t) p' will perform the same conversion as
`(short) p'.

The only case where this wouldn't work is if the system has some
completely insane semantics for pointer conversions.  But in that case,
all bets are off.  Any code which casts from integers to pointers and
back again is already relying on more than the C standard guarantees.

I guess you must be assuming that the intermediate type used
on such a system would be `short', not `intptr_t'.  But that is
not the case.  Re-read the code that I posted earlier in this
thread.  On such a system, it would use `intptr_t'.

> fjh proposes that, if such systems ever become important, gcc can
> treat double-casts as a special case (by not giving warnings).

Or just not issue these warnings at all on such systems.
In other words, treat such systems as a special case
(rather than treating double-casts as a special case).

> I think the idea of incorporating such a special case into the design
> decisions of GCC is distasteful, but a more objective reason why it's
> a bad idea is that it doesn't solve the problem of an
> incorrectly-truncating conversion.

Incorrectly-truncating conversions won't occur.  The only problem here
is just that you appear to have misunderstood which intermediate type
should be used in the double-cast work-around.

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