2014-01-31 Eliot Miranda <eliot.miranda@gmail.com>:

Hi All,

I'd be grateful for a second set of eyes to review my changes in plugin land. The idea here was to eliminate as many isIntegerObject: sends where the intent is to fail if interpreterProxy isImmediate:. There are other cleanups too; some places where it is assumed the start of an object is object + 4 (instead of object + BaseHeaderSize, which hopefully will fix some Spur bugs, where BaseHeaderSize is 8). But there are a fair few fixes and I could have made a mistake.

TIA

Hi Eliot, I'm afraid that so many changes at once has a quite selective effect...

That means significant time and effort to review.

Next time, I suggest distillating bugs on purpose just to check how attentive the list is ;)

I don't know if I where careful enough, but there is only one thing I noticed in #ffiIntegerValueOf:

We now either return a positive32BitValueOf: or a signedMachineIntegerValueOf:

If sizeof(long)==4, then behavior is unchanged, otherwise there is some sort of strange dyssymetry...

Shouldn't it then be positveMachineIntegerValueOf: (does not exist yet ?)

The sender #ffiArgByValue:in: will either pushByte short int or long long (signed or not), but not long so there is an apparent mismatch...
Oh but wait, ffiPushSignedInt:in: calls longAt:put:...
Oh but wait, longAtPut: takes a sqInt...
...which is either an int or a long...
It is very disturbing to follow...

OK, OK, there is no ThreadedFFIIA64Plugin yet, but that's going to be difficult to implement correctly...

Especially if sizeof(int) != sizeof(long), we are going to lack a pushInt pushLong distinction.