2014-07-01 4:22 GMT+02:00 <commits@source.squeak.org>:

Item was changed:
  ----- Method: LargeIntegersPlugin>>cDigitSub:len:with:len:into: (in category 'C core') -----
+ cDigitSub: pByteSmall len: smallLen with: pByteLarge len: largeLen into: pByteRes
+       | z |
- cDigitSub: pByteSmall
-               len: smallLen
-               with: pByteLarge
-               len: largeLen
-               into: pByteRes
-       | z limit |
        <var: #pByteSmall type: 'unsigned char * '>
        <var: #pByteLarge type: 'unsigned char * '>
        <var: #pByteRes type: 'unsigned char * '>

+       z := 0. "Loop invariant is -1<=z<=1"
+       0 to: smallLen - 1 do:
-       z := 0.
-       "Loop invariant is -1<=z<=1"
-       limit := smallLen - 1.
-       0 to: limit do:
                [:i |
                z := z + (pByteLarge at: i) - (pByteSmall at: i).
+               pByteRes at: i put: z - (z // 256 * 256). "sign-tolerant form of (z bitAnd: 255)"

Frankly, having z declared unsigned int and just doing  pByteRes at: i put: (z bitAnd: 16rFF) as I suggested would be way way simpler and will ALWAYS work.
Why the hell invoke the complications of signed arithmetic when the content pByteRes is unsigned???

Even if z is declared signed, (z bitAnd: 255) would work on a vast majority of compiler/processor because most compiler/processor would use a 2-complement representation.
But it's technically implementation-defined.

+               z := z signedBitShift: -8].

i think this one is OK too on a vast majority of machines, but this is as well technically implementation defined.
Some weird compiler/processor pair may as well fill left bits with zeroes, or not even use 2-complement...

z here is a carry and should contain either 0, or -1 (that is UINT_MAX) after this operation.

 
+       smallLen to: largeLen - 1 do:
-               pByteRes at: i put: z - (z // 256 * 256).
-               "sign-tolerant form of (z bitAnd: 255)"
-               z := z // 256].
-       limit := largeLen - 1.
-       smallLen to: limit do:
                [:i |
                z := z + (pByteLarge at: i) .
+               pByteRes at: i put: z - (z // 256 * 256). "sign-tolerant form of (z bitAnd: 255)"
+               z := z signedBitShift: -8].
-               pByteRes at: i put: z - (z // 256 * 256).
-               "sign-tolerant form of (z bitAnd: 255)"
-               z := z // 256].
  !

Isn't there another funny signed shift in Large Integer division?
This would deserve a review too, because division is inlining its own sort of subtraction...