zip64 compatibility problems

Martin Buchholz martinrb at
Sat Jan 26 17:14:03 UTC 2013

On Tue, Jan 15, 2013 at 5:41 PM, Kumar Srinivasan <
kumar.x.srinivasan at> wrote:

>> You changed calls to open to do this:
>>      if ((fd = open(jarfile, O_RDONLY
>> #ifdef O_LARGEFILE
>>          | O_LARGEFILE /* large file mode on solaris */
>> #endif
>> #ifdef O_BINARY
>>          | O_BINARY /* use binary mode on windows */
>> #endif
>>          )) == -1)
>> But this is not done consistently - there are 2 other calls to open in
>> the same file that didn't get the LARGEFILE treatment.  Why isn't
>> there a JLI_Open?
> Maybe if you had reviewed my code changes, you would've caught this. :)
> I will look into it, maybe time for a JLI_Open as you suggested.

Following up on this, I have a simple webrev:

with an "obviously correct" fix.  However:

- we need a bug filed
- This change is completely untested.  I no longer have access to native
32-bit systems where this bug might be manifested.  I have not tried to
actually provoke a failure, although it should not be too hard to create a
3GB jar file with the contents of interest at the end, on a system where
off_t is signed 32-bit.
- As we discussed, it might be better to have a JLI_Open (or even better,
common C-level infrastructure for the whole project) but only you guys have
access to the variety of systems to write and test such a thing, even if it
is just a few lines of code.

So next step here is up to you.

More information about the core-libs-dev mailing list