[PATCH] C undefined behavior fix

[Joseph S. Myers]

On Fri, 4 Jan 2002, Joe Buck wrote:

> What this means, it seems to me, is the following: we have some pointer
> p, which initially points to an array.  We do further operations on it.
> We are allowed to assume that p points somewhere in the array, or one
> past the end.  Now we cast it to an integer.  This is an implementation
> defined operation, yes, but we have defined it.  We could still, at
> this point, make some assumptions about the value of the expression
> for purposes of range propagation analysis.  Now we add an integer
> expression to it.  It is now INVALID to assume that this integer
> expression corresponds to a pointer within the object!

Once the integer has been cast back to a pointer, it is or should be valid
for the implementation to use the provenance of that pointer value to
determine how it can be used, even if the resulting pointer value compares
bitwise equal to a valid pointer.  See DR#260.  This is what GCC is doing
here: defining that the resulting pointers have a certain provenance that
allows them to access only the original object.  If pointers derived by
pointer arithmetic have provenance, then it seems reasonable for those
derived from casts from integers to have it as well.

According to the minutes of the last WG14 meeting, WG14 have not yet
resolved DR#260.  If you disagree with the conclusions we reached in the
UK C Panel about the provenance of pointer values, you could always go to
the next meeting of your National Body and argue that they should take
some other position on that DR at the next WG14 meeting; but it seems
clear to me that being able to take provenance into account is important
for optimisation in the cases given in that DR.

-- 
Joseph S. Myers
jsm28@cam.ac.uk