Re: [PATCH] C undefined behavior fix

["Albert D. Cahalan" <acahalan at cs dot uml dot edu>]

Paul Mackerras writes:
> 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.

These examples make perfect sense. Here is another example, which
you will surely hate:

Consider a machine like the CISC-based (non-PowerPC) AS/400.
There wasn't any hardware-enforced memory protection, but the
OS was secure. Your ability to create a pointer was restricted.
Memory may be flagged as containing a pointer. If you try to
cast something to a pointer and use it, you will fail. Pointers
were 128 bits AFAIK, so they had room for base and offset info.
I'd guess the virtual machine had separate load and store
instructions for pointer and non-pointer data, so that the
pointer flag might be set or cleared as needed.