[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: |
Sven de Marothy |
Subject: |
RE: Patches to java.util.zip by Christian Schlichtherle |
Date: |
Wed, 31 Aug 2005 23:25:53 +0200 |
on Wed, 31 Aug 2005, Christian Schlichtherle wrote:
> 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.
Well, you could do that. But I find that:
long x = (i & 0xFFFFFFFFL);
Converts an unsigned int (i) into a signed long (x) correctly just fine.
/Sven
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 <=