Mojmir Svoboda wrote:
> * Andrew Haley <aph@xxxxxxxxxx> [2008-12-02 11:52:00 +0000]:
>
>>> struct Vector3 {
>>> float x, y, z;
>>> float & operator[] (int i) { return *(&x+i); }
>> This can't work. Well, unless i happens to be zero.
>
> by "cant work" - what conditions do you have in mind? whole code is
> compiled with -fno-strict-aliasing -O1 and this works. if it was not,
> it would be spotted long time ago.
It's undefined behaviour: if you make a pointer by taking the address of an
object you can dereference that pointer. If it's a pointer to an array
you can also increment it up to one past the end of that array. You
can only dereference that pointer if it points to the object you
took the address of.
In this case it'll probably work as long as there is no padding between
x, y, and z. But it's not well-defined code.
>> What *are* you trying to do?
>
> i am actually trying to fix this mess that one guy made long time ago
> (on windows). there are plenty of casts from anything to anything and
> then dereferencing these anythings.
>
> but there is an awful lot of code *depending* on this so i cannot afford
> complete rewrite i am afraid. so i am trying to find easier ways around
> first.
OK, I see. I guess you'll have to proceed slowly, but IMO there is no
point replacing one case of undefined behaviour with another. If you're
going to fix it, you might as well fix it right.
Andrew.
