6541308ff3
The power of two computations here were extremely confusing and one of the comments mixed && and ||. Remove the cached k = j + j value. Optimizing the j*8, j*8, j*2, and j*4 multiplications is the compiler's job. If it doesn't manage it, it was only a couple shifts anyway. With that fixed, it becomes easier to tell that rr was actaully allocated twice as large as necessary. I suspect rr is also incorrectly-allocated in the bn_mul_part_recursive case, but I'll wait until I've checked that function over first. (The array size documentation on the other bn_{mul,sqr}_recursive functions have had mistakes before.) Change-Id: I298400b988e3bd108d01d6a7c8a5b262ddf81feb Reviewed-on: https://boringssl-review.googlesource.com/25364 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com> |
||
---|---|---|
.. | ||
aes | ||
bn | ||
cipher | ||
des | ||
digest | ||
ec | ||
ecdsa | ||
hmac | ||
md4 | ||
md5 | ||
modes | ||
policydocs | ||
rand | ||
rsa | ||
self_check | ||
sha | ||
tls | ||
bcm.c | ||
CMakeLists.txt | ||
delocate.h | ||
FIPS.md | ||
intcheck1.png | ||
intcheck2.png | ||
intcheck3.png | ||
is_fips.c |