On 9/11/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>
> > Well, we have that now:
> >
> > int *q = new int;
> > delete q;
> > int *p = new int;
> > delete p;
> > if (q != p)
> > cout << "different";
> >
> > we cannot optimize the test to be always true. The point is that alias
> > analysis tells us something about accesses to *q and *p, but neither
> > on lifetime of *q and *p nor lifetime of q and p (and thus their value).
>
> That's an interesting example. Thanks for showing it to me. From
> looking at the standard, I think I could be a language lawyer and try to
> argue that the comparison is not defined -- but that would just be
> weaselish; the comparison should be defined. So, yes, I concede that
> you've found a counter-example to my claim that "*p does not alias *q"
> => "p != q". How odd. I would have to revise my claim to require that
> "p" and "q" are valid pointers.
>
> So, for something like:
>
> char *pool;
> void *operator new[] (size_t s) { /* return memory from pool */ }
> ...
> pool = new char[1024];
> char *c = new char[16];
>
> IIUC, your claim is that if pool and c now have the same value, then any
> indirection through pool is invalid (because the object with newest
> lifetime at that location is the 16-byte array), so we can assume *pool
> and *c do not alias? Do you also claim that:
Yes.
> ((char (*)[16])pool)[0] = '\0';
>
> is invalid because it is a pointer "based on" pool?
Yes.
> If you think it's OK to put the "malloc" attribute on operator new, why
> did you say earlier that you can't implement "malloc" in C itself, for
> exactly these kinds of reasons? Isn't the situation exactly analogous?
It looks like, but C doesn't provide us with the notion of dynamic lifetime
of objects at the same memory location. That is, the "newest object"
argument doesn't work in C. In fact this is one reason why we should
not (or can't) put the malloc attribute on obstack_alloc -- it would be
valid to access the obstack memory through the pool pointer.
For C++ we can argue that 'new' starts lifetime of a new object at
the place of the old 'new'ed memory and accesses to the old object
invoke undefined behavior.
> I think I'm getting confused. Perhaps you could sum up in a single
> email the argument for why putting this attribute in our standard
> headers is safe, even in view of possible replacement in user programs?
My argument goes like "We can safely put attribute malloc on all overloads
of new as C++ starts lifetime of a new object in the target and accesses to
old objects at that location invoke undefined behavior". I claim that you
cannot construct a testcase with no undefined behavior that has two
pointers returned from a call to 'new' alias.
Richard.
