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

[Mark Mitchell <mark at codesourcery dot com>]

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
mark@codesourcery.com
(650) 331-3385 x713