zip64 compatibility problems
Martin Buchholz
martinrb at google.com
Sat Jan 26 17:14:03 UTC 2013
On Tue, Jan 15, 2013 at 5:41 PM, Kumar Srinivasan <
kumar.x.srinivasan at oracle.com> 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:
http://cr.openjdk.java.net/~martin/webrevs/openjdk8/LARGEFILE/
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