On 7-Jun-06, at 6:58 PM, Andreas Raab wrote:
Hi Guys -
I don't know if you ever used the above method but it's horribly, horribly broken. I wrote a little test primitive (see below) that simply used signed64BitIntegerFor(signed64BitValueOf(oop)) and then a loop like here:
0 to: 63 do:[:i| n := 1 bitShift: i. (self test64BitInt: n) = n ifFalse:[self halt: i]. ].
Starting from i = 31 Every. Last. Result. Is Wrong. Can you imagine?
It gets even better, since it's broken in different ways: For i=31 the result is negated, for everything beyound 31 the resulting large integer is non-normalized (and therefore not comparing correctly).
Any ideas?
Well for starters the signed64BitIntegerFor: code assumes an 8 byte large integer no matter what the value being converted so that's going to cause your non-normalized problem. I'm fairly sure you can work out how to fix that bit quickly enough.
I'm not absolutely sure(and I can't be bothered to look it up right now) but wouldn't 1<<31 be a negative value when treated as a 32 bit word? It looks to me as if signed32BitInteger might be the wrong thing to use in signed64itInteger, with positive32BitInteger a bit more plausible.
I have vague memories of when this code was written, mostly of it being related to long file pointers in OSs I wasn't running at that time. Thus I would have relied upon testing by involved parties and taken their word as to the viability of the code. I guess that once again the value of good tests is demonstrated.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: VMB: Verify, then Make Bad