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.