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

[Mark Mitchell <mark at codesourcery dot com>]

Richard Guenther wrote:

>> We should optimize away things like:
>>
>>   int *p = new int;
>>   if (!p)
>>     cerr << "Could not allocate memory\n";
> 
> We don't I believe.

That's a missed-optimization, and independent of any attributes on
"operator new".  It's a property of the new *expression*, not of the
implementation of new.  If the compiler treats:

  int *p = new int;

any differently from:

  int &r = *new int;

then we're missing an optimization opportunity.

> though ;)  Well, at least malloc is allowed to return NULL, so unless
> we want to force all malloc attributed functions in C++ to throw exceptions
> we cannot assume they return non-NULL (just on the basis they have
> malloc attribute, that is).

Sure, we can have the attribute in C++ mean the same thing it does in C,
even if that's not the strongest declaration we can make.  That's OK.

But, I don't think that even the C meaning is safe in C++ for use with
the library declaration of <new>.  I'm also somewhat skeptical of the
idea that we will never do any optimization on pointer comparisons.
What design principle in the compiler is going to keep us from some day
introducing the obvious idea that "if modifying *p cannot affect the
value of *q, and p and q are of the same type, then p != q"?

I think that (a) either we have to weaken the meaning of the attribute
in some way, or (b) we let users use this attribute optionally, for
their implementations of operator new when they "know" it's OK to do so,
but do not actually put it in the standard headers.

I'm not arguing that the attribute is meaningless in C++, or does not
apply to the libstdc++ implementation; I'm just arguing that putting it
into <new> is not safe.

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