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:
((char (*)[16])pool)[0] = '\0';
is invalid because it is a pointer "based on" pool?
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?
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?
Sorry,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
