Richard Guenther wrote:
>> 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.
Thanks for explaining your argument. It's very well-reasoned.
However, it still leads to weird results. For example, you're now in a
situation where transforming:
if (p == q)
*p = 3;
to:
if (p == q)
*q = 3;
is not valid. I'd imagine most people to be somewhat surprised by that;
it's rather contrary to the idea of equality. Are we sure we want to go
there?
(This issue does not occur with "restrict", because if the pointers were
known not to alias due to use of "restrict", then the comparison is
always false, by hypothesis -- or else the program behavior is already
undefined.)
>> 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.
I'm not really confident C++ does either. Or, rather, that even if it
does, we should take advantage of that. I'm concerned that we're going
to break a lot of code.
> 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.
Actually, the claim for attribute "malloc" must be even stronger -- the
value returned must not alias *any* other pointer. I don't think that
affects your argument, but just for the sake of clarity, that must be
your claim.
I think my point of view on this is that, whether or not the standard
can be read to support your claim, I don't think we should put the
attribute in our standard headers. I'd rather let people who know what
they're doing put that in their own headers if they want to do so. And,
I'd certainly suggest that we ask the ISO committee before doing this.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
