| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
I broke parsing of integers in bases greater than 10.
Change-Id: I94c4a75c613a1cd8105b7477e68275a81d04d01b
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
From Java 7 on, BigInteger also accepts a leading "+" in its string
constructors.
BigInteger has always claimed to accept non-ASCII digits, but our
implementation never has.
BigInteger.isProbablePrime is defined to return true for certainty <= 0,
but OpenSSL (on which we're based) takes the opposite stance.
Change-Id: I00bfc591a4d583460f71b7eec3de91bf6b03cd87
|
| |
|
|
| |
Change-Id: Ib61b132ce17fdd37956889e855bda35956f8ae62
|
| |
|
|
|
|
|
| |
I've fixed a few typos, and removed a few of the more egregiously nonsensical
or incorrect comments that were nearby.
Change-Id: I35851baebd532f949cc269f4738a26eeb9b6e697
|
| |
|
|
|
|
|
|
|
|
|
| |
OpenSSL's BN library accepts pretty much all input, so if we want to follow
Java's rules, we have to implement them ourselves.
(The FormatterTest change is unrelated and fixes outstanding build breakage
caused by me.)
Bug: http://code.google.com/p/android/issues/detail?id=7036
Change-Id: I0f5413b56fad9289644927672bebf7c3d57e8042
|
| |
|
|
| |
(Plus a bonus item: one Android-written test under luni.)
|
| |\
| |
| |
| |
| | |
Conflicts:
libcore/JavaLibrary.mk
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I started off with a mission to remove uses of dalvik.annotation.* (stuff
like @TestTargetNew and other useless junk that just makes it harder to
stay in sync with upstream). I wrote a script to go through tests showing
me the diff between what we have and what upstream has, thinking that in
cases where upstream has also added tests, I may as well pull them in at
the same time...
...but I didn't realize how close we were to having dx fill its 1.5GiB heap.
After trying various alternatives, I decided to bite the bullet and break
core-tests up into one .jar per module. This adds parallelism back into this,
the slowest part of our build. (I can do even better, but I'll do that in a
separate patch, preferably after we've merged recent changes from master.)
Only a couple of dependencies were problematic: the worthless TestSuiteFactory
which already contained a comment suggesting we get rid of it, and the fact
that some tests -- most notably the concurrent ones -- also contained main
methods that started the JUnit tty-based TestRunner.
(In the long run, we want to be running the harmony tests directly from a
pristine "svn co" of upstream, using DalvikRunner. But this will be a big
help in the meantime, and starts the work of getting our current copy of
the tests into a state where we can start to extract any meaningful
changes/additions we've made.)
|
| |/
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
jessewilson reverted an upstream change (https://issues.apache.org/jira/browse/HARMONY-4623)
that caused an RI incompatibility. Although it seems like the RI behavior is
wrong, the poor design of BigDecimal.equals (which checks both value *and*
scale) probably means we should remain compatible.
This patch changes the test expectation to match the RI's behavior and adds
a comment in both the code and its test explaining that this is deliberate.
|
| |
|
|
| |
Plus other jtreg test scrubbing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
See bug 2183132.
|
| |\
| |
| |
| |
| |
| |
| | |
Merge commit '4b30428421d4ad93d9e6fc34bc0190a5097dc4a6'
* commit '4b30428421d4ad93d9e6fc34bc0190a5097dc4a6':
Fix BigInteger math bugs.
|
| | |
| |
| |
| |
| | |
This initializes the internal representation before doing left shifts.
I'd originally missed this in the first Harmony update; change 20002.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Notable changes:
- lots of trailing whitespace and "@since Android 1.0" tags removed
- shiftLeft(1) replaced with shiftLeftOneBit(). That case can be optimized
more aggressively than the general case. The new method exists in BigInteger
and calls through to a new method in BitLevel in the same way as Harmony.
This is a squashed commit of the following:
commit 3f071487bdb8fff0b4a71ce0219ee7e1e16369fb
Merge: 4fda354 10640b6
Author: Jesse Wilson <jessewilson@google.com>
Date: Tue Aug 4 12:02:25 2009 -0700
Merge branch 'math_772995' into math_dalvik
Conflicts:
libcore/math/.classpath
libcore/math/build.xml
libcore/math/src/main/java/java/math/BigDecimal.java
libcore/math/src/main/java/java/math/BigInteger.java
libcore/math/src/main/java/java/math/Division.java
libcore/math/src/main/java/java/math/Elementary.java
libcore/math/src/main/java/java/math/Logical.java
libcore/math/src/main/java/java/math/MathContext.java
libcore/math/src/main/java/java/math/Multiplication.java
libcore/math/src/main/java/java/math/Primality.java
libcore/math/src/main/java/java/math/RoundingMode.java
libcore/math/src/test/java/tests/api/java/math/BigDecimalTest.java
libcore/math/src/test/java/tests/api/java/math/BigIntegerTest.java
commit 4fda354bd7d2c0ee918c86fa89852310cc8f2af7
Author: Jesse Wilson <jessewilson@google.com>
Date: Wed Jul 29 17:12:27 2009 -0700
Dalvik Math
commit 10640b6b254200f1c89553072e50137f6ad46c84
Author: Jesse Wilson <jessewilson@google.com>
Date: Wed Jul 29 17:11:07 2009 -0700
Math 772995
commit 15302f6d09b3547f1018e3d228f233f8f72c7de9
Author: Jesse Wilson <jessewilson@google.com>
Date: Wed Jul 29 17:08:19 2009 -0700
Math 527399
|
| |
|
|
|
|
|
|
| |
don't work properly in the CTS environment for
some reason.
BUG=1285921
Automated import of CL 148447
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
