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> |
||
---|---|---|
.. | ||
asm | ||
add.c | ||
bn_test_to_fuzzer.go | ||
bn_test.cc | ||
bn_tests.txt | ||
bn.c | ||
bytes.c | ||
check_bn_tests.go | ||
cmp.c | ||
ctx.c | ||
div.c | ||
exponentiation.c | ||
gcd.c | ||
generic.c | ||
internal.h | ||
jacobi.c | ||
montgomery_inv.c | ||
montgomery.c | ||
mul.c | ||
prime.c | ||
random.c | ||
rsaz_exp.c | ||
rsaz_exp.h | ||
shift.c | ||
sqrt.c |