Hi Mike,
On 01/13/2012 09:51 PM, Mike Duigou wrote:
Really cool stuff Joe.
One initial note:
parseUnsigned*() returns a signed value that may not be able to hold the entire
result. I would rather see a larger size be returned to be sure that subsequent
operations don't have to be special cased for> MAX_VALUE. At minimum some
documentation describing the interpretation of negative return values is needed.
The intention of the fooUnsigned methods is that they interpret the 32
or 64 bit value as unsigned. So for example, for parseUnsigned, rather
than recognizing strings representing values between -2^31 and (2^31)-1,
the method recognizes values between 0 and (2^32)-1, mapping results
between 2^31 and (2^32)-1 to what are usually thought of as the negative
values.
I'll take another pass over the new javadoc to try to make this clearer.
Thanks,
-Joe
Mike
On Jan 13 2012, at 21:26 , Joe Darcy wrote:
Hello,
Polishing up some work I've had *almost* done for a long time, please review an
initial take on providing library support for unsigned integer arithmetic:
4504839 Java libraries should provide support for unsigned integer
arithmetic
4215269 Some Integer.toHexString(int) results cannot be decoded back to an
int
6322074 Converting integers to string as if unsigned
http://cr.openjdk.java.net/~darcy/4504839.1/
For the first cut, I've favored keeping the code straightforward over trickier
but potentially faster algorithms. Tests need to be written for the unsigned
divide and remainder methods, but otherwise the regression tests are fairly
extensive.
To avoid the overhead of having to deal with boxed objects, the unsigned
functionality is implemented as static methods on Integer and Long, etc. as
opposed to introducing new types like UnsignedInteger and UnsignedLong.
(This work is not meant to preclude other integer arithmetic enhancements from
going into JDK 8, such as add/subtract/multiply/divide methods that throw
exceptions on overflow.)
Thanks,
-Joe
