Messages in this thread | | | From | Paul Mackerras <> | Date | Sun, 6 Jan 2002 15:09:49 +1100 (EST) | Subject | Re: [PATCH] C undefined behavior fix |
| |
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |