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.
