Re: [PATCH] C undefined behavior fix

[Paul Mackerras]

Joseph S. Myers writes:

> Just because you've created a pointer P, and it compares bitwise equal to
> a valid pointer Q you can use to access an object, does not mean that P
> can be used to access that object.  Look at DR#260, discussing the

I looked at this, and it starts out with an example that includes a
statement free(p); (where p was assigned a value returned from malloc)
and then states that "After the call to free the value of p is
indeterminate."!

This seems absolutely and completely bogus to me.  Certainly, after
the free, the value of *p is indeterminate, but the value of p itself
*is* determinate; its value after the free is identical to its value
before the free.  Why do they say that the value of p itself is
indeterminate after the free?

The two examples of why a compiler might want to change the value are
also bogus; the compiler can avoid writing the value of p from a
register back to memory only if the value is dead, and it isn't in the
example given.  As for the debugging opportunity, if I want p to be
set to NULL or some other pattern for debugging I'll do it explicitly.

In general I think that when a pointer value has been obtained by a
cast to an integer or by passing the address of a pointer to a
function, the compiler should assume that the pointer can point
anywhere.  That means reduced opportunities for optimization, but so
be it.  Note that all of the examples in DR#260 involve passing &p to
some function.

Paul.