Re: [PATCH] C undefined behavior fix

[Joe Buck <jbuck at synopsys dot COM>]

> Joe Buck <jbuck@synopsys.COM> writes:
> 
> > We are defining P2I(p) to preserve bits, and we are defining I2P(i)
> > to preserve bits.  These two definitions, it seems to me, nail down
> > the definition of I2P(P2I(p)+offset).  It simply is not
> > mathematically consistent to define two functions rigorously (three,
> > counting the addition, which does not overflow) and then claim that
> > their composition is undefined. ...
> 
> I think it would be better if you thought of the third paragraph as an
> exception to the second.  That is, if 't' is derived from P2I(q), and
> I2P(t) does not reference the same object as q, I2P(t) is 'undefined'
> rather than the value the previous paragraph would imply.

OK, I've thought about this one some more.  Dewar is right in that there
is not necessarily any inconsistency.  The first two paragraphs
determine the bit pattern that must be computed by the expression.
They do not, however, determine that it is legal to dereference the
resulting pointer, or say that the compiler must take aliasing affects
into account (since the pointer is now out of range, a dereference
could alias with anything).

But what if this odd object is passed to some external function, whose
body is in a different compilation unit?  Then gcc cannot see it,
and furthermore we know the value that must be passed (determined by
I2P, P2I, and +).  The fact that aliasing is undefined doesn't matter,
as a function that we cannot see can modify any global.

This suggests that the approach of -ffreestanding that people objected
to is safe.