On 9/9/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Richard Guenther wrote: > > >> char *pool; > >> void set_pool(char *p) { pool = p; } > >> void *operator new(size_t s) { // return stuff from pool. } > >> > >> bool f() { > >> char *p = new char[1024]; > >> set_pool (p); > >> char *i = new char; > >> return (p == i); > >> } > >> > >> In other words, pointers from any part of the program can potentially be > >> "laundered" through set_pool and return via the new operator. I don't > >> see any way to make this fully safe, in general, without the limitation > >> I imposed: the no-aliasing guarantee only applies to the values returned > >> from the function called. > > > > But in this case an access to *i through *p is invalid. [I suppose both > > new calls are actually different implementations here] Each new > > call starts lifetime of a new object, the previous object lifetime is > > terminated. Even comparing both pointers here for this reason > > would lead to undefined behavior. > > I don't think there's necessarily agreement about that; you're into > what-is-an-object land here... > > In any case, using new to allocate from a pool doesn't invalidate the > pointer to the pool itself. Even if you think reads/writes through *p > are undefined, do you think that comparing addresses is undefined? If > so, how can you still talk about "pool" at all, even in the > implementation of "new" and "delete" themselves, after the first > allocation? > > If comparing addresses is allowed, it's weird to think that: > > if (p == i) > *p = '\0'; > > is invalid, while: > > if (p == i) > *i = '\0'; > > is valid, but I suppose it's possible. > > Do we have any way to guarantee that aliasing information will not be > used when analyzing pointer comparisons, but only when analyzing stores > through pointers?
I don't know of any place we would use such information. At least int *p = new int; int *q = new int; if (p == q) cannot be simplified as both pointers may be NULL? Richard.