zlib 1.2.3 -> 1.2.5

[Xueming Shen]

There is a > 2/4G support issue we will need to address when using the
platform bundled zlib.

The total_in/total_out variables of z_stream_s is "long", which is not "big"
enough (32 bit) for ZIP64 support on a 32-bit platform. The zlib code
bundled with JDK has been updated to use "long long", as the (4)(5)(6)
in ChangeLog_java at

http://cr.openjdk.java.net/~sherman/7110149/webrev/src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java.html

The Deflater/Inflater.getgetByteRead/Written() now use 
z_stream_s.total_in/out
"directly", so it will not be able to report the correct 
totalRead/Written value
if the value > 2G/4G, though it might be rare to deflate/inflate a >2/4G 
chunk
of data.

A possible solution is to accumulate the "totalRead/Written" at java 
level, so
as long as you don't pass in data > 2g/4g in one invocation, it should 
be fine.

-Sherman


On 11/30/2011 02:09 AM, Chris Hegarty wrote:
> On 30/11/2011 09:50, David Holmes wrote:
>> On 30/11/2011 7:43 PM, Alan Bateman wrote:
>>> On 30/11/2011 01:31, Dr Andrew John Hughes wrote:
>>>> On 10:23 Tue 29 Nov , Alan Bateman wrote:
>>>>
>>>> snip...
>>>>
>>>>> When we talked about the zlib version here (I think back in
>>>>> February) we
>>>>> talked about having the option to use the system's zip library where
>>>>> appropriate. Have you given this any thought recently?
>>>>>
>>>>> -Alan.
>>>> We have changes for this (and other libraries) in IcedTea that we'd 
>>>> like
>>>> to upstream. I'll look at posting a webrev soon.
>>> That would be great. If I remember correctly then the IcedTea patches
>>> remove the zlib code completely but we can't do that of course because
>>> of Windows. So I think a USE_SYSTEM_ZLIB as you suggest would be best.
>>
>> FYI the macosx port is also adding a SYSTEM_ZLIB option:
>>
>> http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/
>
> So this is a compile time decision, if you are targeting a platform 
> that is known to have a system zip library you simply link against 
> that. Nice!
>
> I've also been looking at the possibility ( for a different reason ) 
> of using supporting the system version of a library (if one is 
> available) instead of the bundled version. This is to allow support of 
> more recent versions of the system library to be used, rather than 
> what may be an older bundled version, and targets platforms where a 
> system library may or may not be available.
>
> Is this something that may be relevant here, or are we always 
> guaranteed that the system will have a zip library available on our 
> targeted OS-ARCH binaries?
>
> -Chris.
>
>>
>> David
>>
>>> -Alan.
>>>