On Mon, 22 Jan 2024 14:34:25 GMT, Eirik Bjørsnøs wrote:
> @LanceAndersen Do you have a cent or two to spare?
Let me try and dig out from a couple of things and circle back to this again
-
PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1462519461
On Tue, 16 Jan 2024 14:55:39 GMT, Jaikiran Pai wrote:
> I think the only role that a zip64 block should play when we are deciding how
> to parse a data descriptor is whether or not the entry has zip64 extra field
> set (the header id value of the extra field). Does that sound reasonable?
Are
On Tue, 16 Jan 2024 14:41:06 GMT, Eirik Bjørsnøs wrote:
> The spec isn't terribly helpful in spelling out what should happen in the
> case where an entry combines the uses of data descriptors (mandating that
> CRC, size and compressed size must be zero) with Zip64 (mandating that size
> and
On Tue, 16 Jan 2024 13:54:06 GMT, Jaikiran Pai wrote:
>> Eirik Bjørsnøs has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove trailing whitespace
>> - Remove trailing whitespace
>
>
On Tue, 16 Jan 2024 14:34:29 GMT, Eirik Bjørsnøs wrote:
>(These reads are from a temp buffer, not the stream)
Ah! you are right indeed. I didn't correctly read that part of that code. It's
reading from a temp buffer which has been fully initialized with a LOC and
these reads happens with
On Tue, 16 Jan 2024 13:42:30 GMT, Jaikiran Pai wrote:
>> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 534:
>>
>>> 532:
>>> 533: long csize = get32(tmpbuf, LOCSIZ);
>>> 534: long size = get32(tmpbuf, LOCLEN);
>>
>> Hello Eirik, I suspect this part of the
On Wed, 10 Jan 2024 13:39:52 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data
On Wed, 10 Jan 2024 13:39:52 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data
On Wed, 10 Jan 2024 13:39:52 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data
On Tue, 16 Jan 2024 13:40:18 GMT, Jaikiran Pai wrote:
>> Eirik Bjørsnøs has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove trailing whitespace
>> - Remove trailing whitespace
>
>
On Wed, 10 Jan 2024 13:39:52 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data
On Wed, 10 Jan 2024 13:39:52 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data
> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
> number of compressed or uncompressed bytes read from the inflater is larger
> than the Zip64 magic value.
>
> While the ZIP format mandates that the data descriptor `SHOULD be stored in
> ZIP64 format (as 8 byte
13 matches
Mail list logo
