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 _______________________________________________ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath