[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Patches to java.util.zip by Christian Schlichtherle
From: |
Christian Schlichtherle |
Subject: |
RE: Patches to java.util.zip by Christian Schlichtherle |
Date: |
Wed, 31 Aug 2005 14:42:54 +0200 |
Hi everyone,
> Yes, if someone can make a little testcase where we fail now
> and show how we are not properly converting the
> signed/unsigned ints at the moment that would be appreciated.
> Note that at the moment all public methods take and return
> longs already, we only store it as int internally and try
> treat it as unsigned already. It might be that we need to
> internally store everything in an long and not just treat the
> signed ints as unsigned ints as we do now in the code, but
> the patch contained so many unrelated changes that it was
> hard to make out which changes were explicitly for this
> issue. So if someone could extract those parts of the patch
> that would help a lot.
More specifically, the size and compressed size field in the ZipEntry class
are causing the problems as some comparisons are happening on these. The
issue is that once a big integer equal or greater than 2*1024^3 and smaller
than 4*1024^3 is stored into a Java int, it is hard to use this int as if it
were unsigned. You would have to do something like this on an int
(untested):
final static long NUM_FOUR_BYTE_INTS = 256L * 256L * 256L * 256L; // Number
of 4 byte ints
private static long int2long(int i) {
return i >= 0 ? (long)i : (long)NUM_FOUR_BYTE_INTS - (long)i;
}
private static void doIt() {
int ok = 2 * 1024 * 1024 * 1024 - 1; // max signed int
int tooBig = 3 * 1024 * 1024 * 1024; // Creates a negative integer
// Compare ok and tooBig
assert int2long(ok) < int2long(tooBig) : "This is ok!";
assert ok < tooBig : "This fails!";
}
This is way too much computational overhead and it is way too easy to forget
this on a comparison. Thus, the better way to deal with this issue is hold 4
byte signed ints in a Java long if you don't need to care for the memory
overhead.
With best regards,
Christian
smime.p7s
Description: S/MIME cryptographic signature
RE: Patches to java.util.zip by Christian Schlichtherle, Jeroen Frijters, 2005/08/31
RE: Patches to java.util.zip by Christian Schlichtherle, Sven de Marothy, 2005/08/31