I'm trying to implement an existing network protocol which makes heavy use of Unsigned datatypes, which are not supported by Java. What I currently do is for each datatype, chose the next bigger one so that the unsigned number may fit into the positive region and then use byte shifting to get the desired effect. Since this is pretty error prone and for an unsigned long onward I have to use BigInteger which is a lot heavier than expanded types, I was wondering if there isn't a better way to achieve this?
Asked
Active
Viewed 2.5k times
1 Answers
16
Depending on what you are doing, you can just treat long as a 64-bit value and int as a 32-bit value. Most operations esp readInt/Long writeInt/Long work just the same by ignoring the signness.
Can you give an example of operation you perform on these numbers and perhaps we can suggest how would do the same thing without having to expand the type.
For example, ++, --, +, -, *, ==, !=, << all work the same regardless of signess (i.e. give the same answer). for >> you can substitue >>>
It is the /, %, >, >=, <, <= and printing functions which assume signed values, but you should be able to work around these (if you use these).
e.g.
long unsignedA =
long unsignedB =
boolean greater = unsignedA + Long.MIN_VALUE > unsignedB + Long.MIN_VALUE
EDIT: Why does this work? Partly because java doesn't have overflow/underflow exceptions.
e.g.
byte unsignedA = 0;
unsignedA--;
// unsignedA == FF, is this -1 or 255? Java assumes the former but you assume the later
byte unsignedB = unsignedA * unsignedA;
// unsignedB is -1 * -1 = 1 or (byte) (255*255) = (byte) 65525 = 1.

Peter Lawrey
- 525,659
- 79
- 751
- 1,130
-
Hm, that sounds promising, I was hoping to just create an InputStream and from thereon just work with the values as expected, instead of dragging them around in the program. Problem is that for the most part they represent IP addresses, version numbers (very heavy on >, <, <= and >=), cryptohashes (no problem there, probably) and timestamps (again heavy on comparisons). – cdecker Dec 15 '10 at 11:16
-
For IP addresses, you will need to use baising trick or extend to long. for long timestamps, you should be able to assume they are between 0 and Long.MAX_VALUE if they are in milliseconds. Do your version numbers use the top bit either? Can you give an example of one which does? (if so you need to bias the comparison also) – Peter Lawrey Dec 15 '10 at 11:24
-
Signed long milli-second timestamps are limited to year 292,471,208 if you start at 1 BC (there was no year 0), – Peter Lawrey Dec 15 '10 at 11:27
-
Sadly I cannot change the protocol itself, but you are right that I can just ignore higher bits in timestamps (they are in seconds from 01.01.1970...). Yes the guy designing the protocol did some really bad choices :-) – cdecker Dec 15 '10 at 12:54
-
@cdecker, so if you ignore the top bit for seconds you can still go to year 293 billion, give the sun only has 6 billion years of life left... ;) biasing the date by 1970 was rather pointless. ;) He could have don't micros-econds since 1 BC and you still wouldn't have a problem I suspect. – Peter Lawrey Dec 15 '10 at 16:56
-
@PeterLawrey How could we shift a long unsigned value for example? (Imaging I'm trying to store a 64-bit integer value into an 8-bytes array) – Feb 26 '13 at 13:07
-
@Desolator You can use `>>>` for unsigned bit shifting. – Peter Lawrey Mar 05 '13 at 23:07