Thanks Martin1
We are very close:-)
Here is the latest webrev, compared to the last one, the only changes are
(1)zcrc.c, the "compromised" change you approved.
(2)undo any change in crc.h
(3)a final tweak in zlib.h, this one is used by nobody and never
exported. Just to make compile happy
21 -ZEXTERN const unsigned long FAR * ZEXPORT get_crc_table OF((void));
22 +ZEXTERN const uLongf * ZEXPORT get_crc_table OF((void));
http://cr.openjdk.java.net/~sherman/zlib123/webrev
Tests (all related jar/zip/pack/unpack tests, LargZip, jar c/x/t of
large(>6g) zip, pack200/unpack200 of rt.jar,
ZlibTest on all standard jdk jar lirbraries) have been done on Solaris
sparc/i586 32-bit &64-bit, Linux 64-bit,
Windows XpVista 32-bit and 2003 Server 64-bit. One last test is still
running on a sparc 32-bit (jar up single > 6G file).
Let me know if you guys are OK with the latest one.
Sherman
Martin Buchholz wrote:
On Mon, Aug 24, 2009 at 15:24, Xueming Shen<xueming.s...@sun.com> wrote:
Martin Buchholz wrote:
I imagine that the only issue with having unsigned long be 64-bit is that
crc32.c will compute a 32-bit integer, it will get widened to 64-bit,
and then narrowed back to 32-bit, which is allowed in C and harmless
(although there might be a warning),
but not in Java, where you have to explicitly cast to throw away the
top 32 bits.
Martin
Given "uLong" is used widely in zlib.h, I would like to keep it asis (to be
32-bit as we have been doing
for years). So the question is can you live with the following simle "local
change" in crc32.c. crc32.h therefor
will remained untouched, the same as the original zip (which means the crc32
is calculated on 64-bit
actually, I'm not sure the impact of "register u4 c" will have, but believe
it will use up a full 64-bit register
anyway).
--- /home/sherman/TL/zlib-1.2.3_ORG/crc32.c Sun Jun 12 16:56:07 2005
+++ ../../../src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c Mon Aug 24
15:10:22 2009
@@ -216,8 +216,8 @@
#define DO8 DO1; DO1; DO1; DO1; DO1; DO1; DO1; DO1
/* =========================================================================
*/
-unsigned long ZEXPORT crc32(crc, buf, len)
- unsigned long crc;
+uLong ZEXPORT crc32(crc, buf, len)
+ uLong crc;
const unsigned char FAR *buf;
unsigned len;
{
@@ -234,9 +234,9 @@
endian = 1;
if (*((unsigned char *)(&endian)))
- return crc32_little(crc, buf, len);
+ return (uLong)crc32_little(crc, buf, len);
else
- return crc32_big(crc, buf, len);
+ return (uLong)crc32_big(crc, buf, len);
}
#endif /* BYFOUR */
crc = crc ^ 0xffffffffUL;
I approve of this compromise, and also
approve of making the corresponding change to
crc32_little and crc32_big, if you wish to do that.
It should be a safe change, and "much less" than the original one:-) If
you're OK with this, I can go kick start
the build and test.
btw, I really don't like the big/littleendian detecting code...but should
not be a big deal if mostly we do bulk
calculation.
endian-detection should happen at configure-time, not run time.
But zlib does not have a history of an extensive "configure layer".
And I don't think it is possible to determine endian-ness using
only the C preprocessor. Hence the current situation.
Martin
