zlib1.2.3

[Xueming Shen]

Martin Buchholz wrote:
> On Fri, Aug 21, 2009 at 11:09, Xueming Shen <Xueming.Shen at 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