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

["Richard Guenther" <richard dot guenther at gmail dot com>]

On 9/9/07, Mark Mitchell <mark@codesourcery.com> wrote:
>
> 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"?

But that reasoning is not valid.  Consider

 void foo(int *q, double *p)
 {
    if (q != p)
      abort ();
 }
 int main()
 {
   int i;
   foo (&i, &i);
 }

which would abort.  Now, instead

void foo(int *q, double *p)
{
  *q;
  *p;
  if (q != p)
    abort ();
}

we can optimize the comparison to alwas true as in the case
of p == q the program invokes undefined behavior.  The essence
is that we usually cannot tell anything about pointer values and
pointed-to types unless we see accesses through them.

> 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.

Today we should be safe I believe.  Even if we inline new (we'd lose
knowledge about the call in this case -- which we of course may
fix in future).

It would be nice to have some testcases in the testsuite with the ideas
that pop up around these discussions though :)

Richard.