Robert Dewar <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| >It highly depends on what you define to be pointer arithmetic.
| >
| >Given the conversions
| >
| > pointer -> integer type
| > integer type -> pointer
| > T* -> U*
| >
| Yes, but the only defined semantics of these conversions is that you
| get the same
| pointer back, you cannot say anything else about the values. If you
You get the same pointer back, *when* you've done a round trip.
For
pointer type -> integer type
or
integer type -> pointer type
or
T* -> U*
there is no "round trip" requirement for the values to be ligt.
However, we have an obligation to define what those mappings are.
| add one to
| the integer, you have no assurance that it has anything to do with
| adding one
| to the pointer.
No dispute on that.
| Yes, it probably will, but there is no guarantee in
| the standard.
|
| >I think your sentence is way to restrictive and does not capture C
| >models.
| >
| Well part of the trouble is that there are really two models here, the
| one in the
| standard, and the one that everyone expects and which is by and large
| the one
| that is implemented.
yes, and I should have been more precise: even the standard model is
not captured.
|
| >Richard, to resolve this issue, we need to be more precise about our
| >mappings for
| >
| > pointer -> integer type
| > integer type -> pointer
| > T* -> U*
| >
| >conversions. This is not an issue to resolved in isolation, piece meal.
| >
| There is no obligation standard-wise to say anything at all about
| these conversions,
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.
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).
-- Gaby
