Re: [RFC] Marking C++ new operator as malloc?

[Mark Mitchell <mark at codesourcery dot com>]

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?

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713