Fwd: [Vm-dev] Interpreter>>signed32BitValueOf: and signed64BitValueOf: broken

Andreas Raab andreas.raab at gmx.de
Wed Nov 26 03:03:17 UTC 2008


It shouldn't fail; it's a bug. Unfortunately, I have no time to fix it.

Cheers,
   - Andreas

John M McIntosh wrote:
> 
> Just to clarify with the current VMMaker source code and the FFI plugin 
> if I do
> 
> | foo |
> foo := ByteArray new: 4.
> foo signedLongAt:1 put:  -2147483648
> 
> that fails, should it?
> 
> 
> Begin forwarded message:
> 
>> From: John M McIntosh <johnmci at smalltalkconsulting.com>
>> Date: November 23, 2008 11:27:14 PM PST (CA)
>> To: Squeak Virtual Machine Development Discussion 
>> <vm-dev at lists.squeakfoundation.org>
>> Cc: Andreas Raab <andreas.raab at qwaq.com>, "David T. Lewis" 
>> <lewis at mail.msen.com>
>> Subject: Re: [Vm-dev] Interpreter>>signed32BitValueOf: and 
>> signed64BitValueOf: broken
>> Reply-To: johnmci at smalltalkconsulting.com
>>
>> Er is this still broken?
>>
>> I was writing some Sunits for the Alien stuff and found
>>
>> alien signedLongAt: 1 put: -1*16r80000000.  " -2147483648"
>> failed.
>> triggered by   value < 0 ifTrue:[^self primitiveFail].
>> as coded below
>> since value is -2147483648
>>
>> range is Signed: −2,147,483,648 to +2,147,483,647
>> http://en.wikipedia.org/wiki/Integer_(computer_science)
>>
>>
>>
>> On 19-Mar-08, at 8:44 PM, Andreas Raab wrote:
>>
>>> Hi -
>>>
>>> I just noticed hat Interpreter>>signed32BitValueOf: and 
>>> signed64BitValueOf: are broken for edge cases. The following example 
>>> will illustrate the problem:
>>>
>>> array := IntegerArray new: 1.
>>> array at: 1 put: 16rFFFFFFFF. "should fail but doesn't"
>>> array at: 1. "answers -1 incorrectly"
>>>
>>> array := IntegerArray new: 1.
>>> array at: 1 put: -16rFFFFFFFF. "should fail but doesn't"
>>> array at: 1. "answers 1 incorrectly"
>>>
>>> The problem is that both signed32BitValueOf: as well as 
>>> signed64BitValueOf: do not test whether the high bit of the magnitude 
>>> is set (which it mustn't to fit into a signed integer). The fix is 
>>> trivial in both cases - basically all that's needed at the end of 
>>> both functions is this:
>>>
>>> "Filter out values out of range for the signed interpretation such as
>>> 16rFFFFFFFF (positive w/ bit 32 set) and -16rFFFFFFFF (negative w/ bit
>>> 32 set). Since the sign is implicit in the class we require that the
>>> high bit of the magnitude is not set which is a simple test here"
>>> value < 0 ifTrue:[^self primitiveFail].
>>> negative
>>>   ifTrue:[^0 - value]
>>>   ifFalse:[^value]
>>>
>>> Cheers,
>>> - Andreas
>>
>> -- 
>> =========================================================================== 
>>
>> John M. McIntosh <johnmci at smalltalkconsulting.com>
>> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
>> =========================================================================== 
>>
>>
>>
>>
> 
> -- 
> ===========================================================================
> John M. McIntosh <johnmci at smalltalkconsulting.com>
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
> 
> 
> 


More information about the Vm-dev mailing list