On Fri, 29 Apr 2005 16:32:09 -0400, Dave Mason dmason@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 code:
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.
../Dave
vm-dev@lists.squeakfoundation.org