This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: optimization bug
- To: Dima Volodin <dvv at dvv dot ru>, Alexandre Oliva <oliva at dcc dot unicamp dot br>
- Subject: Re: optimization bug
- From: bonnardv at pratique dot fr (Valentin Bonnard)
- Date: Tue, 27 Oct 1998 19:03:19 +0100
- Cc: egcs-bugs at cygnus dot com
A (At) 12:50 27/10/98, Dima Volodin ecrivait (wrote):
>> comp.std.c++ about a similar issue, namely, is &array[3] valid if
>> array is define to have three element? Or must one use array+3?
>And what if you re-define & for the base class of _array_ here?
This case is explicitly eliminated (as a special case).
>Anyway, has
>this thread ended with any definitive outcome?
To me, it has always been very clear that the behaviour is undefined
and no one had any arguments proving the contrary. The issue isn't
how the behaviour should be defined but how it is actually defined.
You can't dereference a null pointer. There isn't any ambiguity.
>As of my own opinion - I
>tend to consider passing *(T*)0 by reference as a perfectly valid construct
>(together with this &array[3]) as
It isn't
>I don't see it any more different (and
>dangerous) than the zero pointer.
I agree. They are as undefined as each other.
Valentin Bonnard mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/