Martin Buchholz wrote:
On Fri, Aug 21, 2009 at 11:09, Xueming Shen <xueming.s...@sun.com> wrote:
Martin, webrev has been updated to
(1)use unidiff (and the correct order of src and target)
(2)put those diffs into a patches dir
(3)remove the minigzip.c from the ws (this one is not included in the file_c
list...)
Thanks.
-------------
35 +/* for _LP64 */
36 +#include <sys/types.h>
37 +
38 /*
39 * If you *really* need a unique prefix for all types and
library functions,
40 * compile with -DZ_PREFIX. The "standard" zlib should be
compiled without it.
41 @@ -261,7 +288,11 @@
42 typedef unsigned char Byte; /* 8 bits */
43 #endif
44 typedef unsigned int uInt; /* 16 bits or more */
45 +#ifdef _LP64
46 +typedef unsigned int uLong; /* 32 bits or more */
47 +#else
48 typedef unsigned long uLong; /* 32 bits or more */
49 +#endif
zlib (intentionally) doesn't have much of a configure layer,
so we take our best shots at portability.
I think the above probably works fine, but I would do the very simple
typedef unsigned int uLong;
sure. if this is important for you, I can make the change as you
suggested. I have just finished
all the testing on the platforms I can get here (solaris sparc 32-bit,
solaris x86 32-bit, linux 64-bit,
windows xp 32bit, vista 32-bit and windows 2003 64-bit). The
regression/unit tests have been
on all platforms via jprt. So I will have to go through the build/test
circle again if I'm going to
make this change:-) provided you are convinced that keep the crc32 asis...
since unsigned int is likely to be 32 bits on any platform the JDK
is ever likely to run on. Only early Dec Alpha systems made the mistake
of having a 64-bit int.
The 32-bit vs. 64-bit types are a mess. I notice that crc32 tries to define
its own "u4" portability type
-------------
31 @@ -39,7 +63,7 @@
32 typedef unsigned int u4;
33 # else
34 # if (ULONG_MAX == 0xffffffffUL)
35 - typedef unsigned long u4;
36 + typedef uLong u4;
37 # else
38 # if (USHRT_MAX == 0xffffffffUL)
39 typedef unsigned short u4;
Using uLong in the above is probably not right,
since comparison against ULONG_MAX means
the corresponding type is unsigned long
(not that it matters)
uLong is unsigned long on the 32-bit platform and on a 64-bit platform the
ULONG_MAX should not be 0xffffffffUL. My understanding is that as
long as the u4 is a "unsigned 4-byte" type, we are OK. The crc32 value
is a unsigned 32-bit integer. The zlib1.1.3 does use the uLong, which is
consistent with the rest of the code base, it's kind of strange that the
crc32
of the 1.2.3 starts to use its own style of "unsigned long".
I'm suspicious that the changes in crc32.c might not be needed,
because nobody else is having to make these changes.
Perhaps use of "unsigned long" in crc32.c is correct because
in these cases either a 32-bit or 64-bit type will do?
Did you actually encounter functional problems with the original code?
pack code at src/share/native/com/sun/java/util/jar/pack/zip.cpp expects
the crc32() returns
a "uint", it actually matches the uLong. So there is a compiling err on
64-bit platform if we keep
crc32 un-touched. Sure, its possible to solve this problem by changing
the pack code...first I
would like to avid to touch pack code if possible, second asI said
above, crc32 is a unsigned
32-bit, it seems right to simply use the unsigned 32-bit.
sherman
