Sunday, September 10, 2006

Pitfalls of Long.parseLong/Long.decode...

What is wrong with this code?
assert 0x0cc175b9c0f1b6a8L == Long.parseLong("0cc175b9c0f1b6a8",16);
assert 0xd41d8cd98f00b204L == Long.parseLong("d41d8cd98f00b204",16);
The second Long.parseLong will fail in the second line:
java.lang.NumberFormatException: For input string: "d41d8cd98f00b204"
The reason is that javas long is signed, but 0xd41d8cd98f00b204L is an unsigned long. Interesting, but annoying, if you want to parse an unsigned long in java. It makes Parsing and verifying hex, octal and decimal numbers more complicated, if you have a field that represents a C/C++ unsigned long (a 64 bit number)....

The solution is to use BigInteger:
assert 0x0cc175b9c0f1b6a8L == new BigInteger("0cc175b9c0f1b6a8",16).longValue();
assert 0xd41d8cd98f00b204L == new BigInteger("d41d8cd98f00b204",16).longValue();
However, you must ensure that the BigInteger does not exceed 64 bits. So here's my unsigned long parser
public static long parseUnsignedLong(String s, int radix) 
throws NumberFormatException {
BigInteger b= new BigInteger(s,radix);
throw new NumberFormatException(s+" is to big!");
return b.longValue();
Note: if you want to do any kind arithmetic with unsigned longs (like min/max checking) you have to use BigInteger objects.... Unless you are only interested in the bits of the long, the return value of my parseUnsignedLong is not really useful: it should better return the BigInteger!

No comments:

Post a Comment