| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
The >= versus > bug was fixed in openssl somewhere between .98g and .98k (we
don't have _all_ versions conveniently lying around), and our removal of
the disjunct was irrelevant. Call the now-correct upstream code instead of
manually inlining and hacking it.
Also rename BN_lshift to BN_shift, since it handles both left and right shifts.
|
| |
|
|
| |
...and switch all NPE throwers over to the helper.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
valgrind complains about invalid 4-byte reads, caused by "case 8" in the
BNInterface.c function I'm removing here, which assumed that if we're checking
whether a BIGNUM fits in 8 bytes, it must require more than 4 bytes (and so
accessing d[1] is acceptable).
We can implement this in Java using the existing BigInteger.bitLength
method (which may call down to native code, but that native code looks okay).
Also remove a related commented-out method.
Bugs: 2223213, 2225642
|
| |
|
|
|
|
| |
If GetPrimitiveArrayCritical fails, it throws a suitable exception for us.
Also remove dead code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NativeBN_bn2twosComp doesn't do what it claims to: it's an exact copy of
NativeBN_BN_bn2bin (observe which OpenSSL BN_ function it calls!), and -- from
the OpenSSL documentation -- that function "converts the absolute value of [its
argument] into big-endian form".
OpenSSL doesn't actually sport any appropriate function to call here, but
luckily this code isn't called anywhere, and so can be removed.
(BigInteger.toByteArray -- the most likely caller of this code -- seems to
do the right thing, using Java code to make a big-endian two's-complement
byte[]. Likewise, the conversion from a big-endian two's-complement byte[]
for the corresponding BigInteger constructor looks right too, using native
code to twiddle the bits itself.)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
