PR 25512: pointer overflow defined?

[Robert Dewar]

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 add 
one to
the integer, you have no assurance that it has anything to do with 
adding one
to the pointer. 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.

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

>-- Gaby
>  
>