Hi Matthias, thanks for the update.
I still think you should avoid introducing a file parse_manifest_md.c. As per my previous mail, you should think of a JLI_open function and then you can put its implementation into the Windows version of java_md.c. You can take example on the implementation of JLI_Snprintf which has coding on Windows and for Unix it's just a #define to snprintf. Would it be possible to add a jtreg testcase that shows/tests the issue? Best regards Christoph > -----Original Message----- > From: Baesken, Matthias > Sent: Montag, 28. Januar 2019 12:38 > To: Alan Bateman <alan.bate...@oracle.com>; core-libs- > d...@openjdk.java.net > Cc: Langer, Christoph <christoph.lan...@sap.com> > Subject: RE: RFR : 8217093: Support extended-length paths in > parse_manifest.c on windows > > Hello Alan / Christoph, > new webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.3/ > > - moved ELP_PREFIX define out of the function > - added a check (wfullnamelen > 247) before CreateFileW is attempted > - some other formatting (mostly suggested by Christoph) > > > Best regards, Matthias > > > > -----Original Message----- > > From: Alan Bateman <alan.bate...@oracle.com> > > Sent: Sonntag, 27. Januar 2019 16:57 > > To: Baesken, Matthias <matthias.baes...@sap.com>; core-libs- > > d...@openjdk.java.net > > Cc: Langer, Christoph <christoph.lan...@sap.com> > > Subject: Re: RFR : 8217093: Support extended-length paths in > > parse_manifest.c on windows > > > > On 24/01/2019 16:19, Baesken, Matthias wrote: > > >> Did you consider adding a Unix version of open_jarfile to avoid #ifdef > > >> WIN32 ? > > > Hi Alan, do you mean , adding a separate c-file for UNIX containing the > > function open_jarfile ? > > > I considered this, but did not like the idea to add a separate file for > > > UNIX > > just for the small function . > > > > > > Your suggestion to use FILE_SHARE_READ is probably the right way to > do > > it , I changed this, second webrev : > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.2/ > > > > > Christoph Langer's suggestion to use jli_util seems worth exploring to > > keep the platform specific code together. > > > > I still find the call to _open and checking for ENOENT a bit icky. If > > this change gets pushed then I think we need a follow-up issue created > > to replace this to use CreateFile consistently. > > > > -Alan
