InterpreterProxy>>signed64BitIntegerFor: badly broken
tim at rowledge.org
Thu Jun 8 05:02:40 UTC 2006
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
> 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
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 Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: VMB: Verify, then Make Bad
More information about the Vm-dev