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