InterpreterProxy>>signed64BitIntegerFor: badly broken

tim Rowledge tim at
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  
> 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 Rowledge; tim at;
Strange OpCodes: VMB: Verify, then Make Bad

More information about the Vm-dev mailing list