>>>>> On Fri, 29 Apr 2005 16:32:09 -0400, Dave Mason <dmason(a)sarg.ryerson.ca> said:
I have the source (without VMMaker because of a permission problem),
and I looked at FloatArrayPlugin. The code there looks fine if the
longAt is replaced with floatAt or intAt. It stores a block of floats
starting at the first field in the object.
However there definitely is *potential* for a problem if you had a
collection of fields some of which were floats.
Here's where there could be a problem on 64 bit, where
sizeof(sqInt)==8 and sizeof(float)==4.
Consider a block of memory: abcdefgh ijklmnop qrstuvwx
1stIndexableField returns the address of 'a'; assume the following
sqInt argOop = oopForPointer(interpreterProxy->firstIndexableField(arg));
float* argFlo = (float *)(interpreterProxy->firstIndexableField(arg));
sqInt* argOopp = (sqInt *)(interpreterProxy->firstIndexableField(arg));
floatAt(argOop) gets abcd
floatAtPointer(argFlo) gets abcd
floatAtPointer(argOopp) gets abcd
Fine so far, but:
floatAt(argOop+1) gets bcde (or error)
floatAtPointer(argFlo+1) gets efgh
floatAtPointer(argOopp+1) gets ijkl
floatAt(argOop+2) gets cdef (or error)
floatAtPointer(argFlo+2) gets ijkl
floatAtPointer(argOopp+2) gets qrst
As far as I can see, abcd, ijkl, and qrst are the right answers (if
they are fields containing floats), with efgh being garbage and ijkl
not being the correct answer in the 3rd example.
So *anywhere* you are skipping through a bunch of fields, you need to
do the pointer arithmetic with sqInt*. As I said before, this is a
pretty subtle error, but a quick grep through the code for
1stIndexableField shows a lot of _potential_ problems, although all in
plugins, and many of them have to do with arrays, so they probably aren't.
All of this may be obvious to Ian and the rest of you, but I'm trying
to learn a bit about the code, and this was a useful exercise for me.