[squeak-dev] Re: Fixing SecureHashAlgorithm without plugins
timfelgentreff
timfelgentreff at gmail.com
Thu May 19 08:37:22 UTC 2016
Hi Levente,
thank you, that change works great for me :)
Cheers,
Tim
Levente Uzonyi wrote
> Hi Tim,
>
> I made a workaround using #adoptInstance: instead of copying in
> System-ul.831. Hopefully you have one of the primitives (160, 115) it uses
> implemented.
> I think it would be worth moving the fallback code from Integer down to
> LargePositiveInteger, because that way SmallInteger receivers would
> signal DNU instead of 'You can''t store in a SmallInteger'.
>
> Levente
>
> On Thu, 19 May 2016, timfelgentreff wrote:
>
>> Hi,
>>
>> we're running the fallback code for SecureHashAlgorithm,
>> LargePositiveInteger, and lots of the optional primitives. In the
>> fallback
>> code of SecureHashAlgorithm>>finalHash there is a call that looks like
>> this:
>>
>> (LargePositiveInteger new: result size)
>> replaceFrom: 1
>> to: result size
>> with: result
>> startingAt: 1;
>> normalize
>>
>> Here, result is a ByteArray. The replaceFrom:to:with:startingAt: goes to
>> call primitive 105, which is marked as optional in the comment, so we do
>> not
>> implement it. However, the fallback code in
>> Integer>>replaceFrom:to:with:startingAt: sends digitAt: to the
>> replacement
>> object, and ByteArray doesn't understand that message.
>>
>> Clearly the fallback code behaves differently from the primitive.
>>
>> 1) One way to fix it would be to check the object type in the fallback
>> code.
>> If it is a byte object, we simply use at: (which is the same as digitAt:
>> for
>> Large*Integer).
>>
>> 2) Another fix is to add digitAt: to ByteArray. This feels very wrong to
>> me.
>>
>> 3) Alternatively, we might say that calling
>> replaceFrom:to:with:startingAt:
>> on an integer with any byte object is illegal. In that case, we could
>> instead fix the fallback code in SecureHashAlgorithm>>finalHash to do
>> this
>> in the end:
>>
>> LargePositiveInteger adoptInstance: result.
>> ^ result normalize
>>
>> This will fix the problem, but the fallback code will still be
>> inconsistent
>> with the primitive.
>>
>> I'm torn between 1 and 3, so what do you say?
>>
>> Cheers,
>> Tim
>>
>>
>>
>> --
>> View this message in context:
>> http://forum.world.st/Fixing-SecureHashAlgorithm-without-plugins-tp4895951.html
>> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>>
>>
--
View this message in context: http://forum.world.st/Fixing-SecureHashAlgorithm-without-plugins-tp4895951p4895970.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.
More information about the Squeak-dev
mailing list
|