This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: optimization bug


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/




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]