On Wed, 21 Dec 2005, Gabriel Dos Reis wrote:
> There is:
>
>
> [#5] An integer may be converted to any pointer type.
> Except as previously specified, the result is
> implementation-defined, might not be correctly aligned,
> might not point to an entity of the referenced type, and
> might be a trap representation.56)
>
> [#6] Any pointer type may be converted to an integer type.
> Except as previously specified, the result is
> implementation-defined. If the result cannot be represented
> in the integer type, the behavior is undefined. The result
> need not be in the range of values of any integer type.
>
> and
> 3.4.1
> [#1] implementation-defined behavior
> unspecified behavior where each implementation documents how
> the choice is made
>
> | other than they are value preserving, i.e. if you convert a pointer to
> | an integer
> | that is large enough, and back to a pointer, you get the pointer
> | back. As far as I
> | know nothing more can be said.
>
> What need is to document what mapping is used to compute the result of
> the conversion. Till now, people have assumed that GCC wouold use the
> "obvious" model and write codes based on that. On the other hand, GCC
> has been getting more "aggressive" (I don't quite like the word)
> transformations and things start breaking. That ask for more precise
> documentation.
We do:
4.7 Arrays and pointers
* The result of converting a pointer to an integer or vice versa (C90
6.3.4, C99 6.3.2.3).
...
> As for the comparison, lots of C programs do things like comparing for
> equality to (void *)-1; it is a question as whether you'll declare
> such programs as having undefined behaviour (if yes, I don't see how)
> or have implementation-defined semantics (if yes, then we need to say
> what can be done to such pointers).
I think equality comparisons are not a problem, imposing an ordering
on the bit-representation of pointers is, though (as the std doesn't
require this).
Richard.
