Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!elroy.jpl.nasa.gov!ncar!gatech!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: Dereferencing Typecast Integer Literals
Message-ID: <15081@smoke.brl.mil>
Date: 5 Feb 91 19:35:10 GMT
References: <15067@smoke.brl.mil> <1991Feb4.234142.26867@watmath.waterloo.edu>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 22

In article <1991Feb4.234142.26867@watmath.waterloo.edu> datangua@watmath.waterloo.edu (David Tanguay) writes:
>In article <15067@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
>>Also, each implementation is required to
>>provide SOME integral type to which any data pointer can be cast such
>>that upon subsequent cast back to the same type of pointer, the new
>>pointer value will compare equal to the old value.
>Where does the standard say this?  3.3.4 says a pointer may be converted
>to some integral type, and that an integer may be converted to a pointer,
>but the result is implementation defined.

Oops, you're right.  The base document made the guarantee, but somewhere
along the way X3J11 decided that it was impractical to guarantee that
the same representation would be obtained upon reconversion to a pointer,
and that they did not want to require implementation of the "equivalence
class" notion for pointer equality that I mentioned previously.  There is
an even more insidious problem lurking in the way the standard ended up,
which is that an ARBITRARY integral value must be convertible to any
pointer type, whether or not alignment and address bound requirements are
met.  This could cause implementations to have to perform some extra work
when an integer is converted to some pointer types.

Sorry for relying on my fuzzy memory instead of on the standard..