On 9/9/07, Mark Mitchell <[EMAIL PROTECTED]> 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.
