RFR: 8165643: SecureDirectoryStream doesn't work on linux non-x86

[Martin Buchholz]

I pushed this fix, but also created the obvious follow-on fix
https://bugs.openjdk.java.net/browse/JDK-8165776
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/SecureDirectoryStream-non-x86-32bit/
Completely untested, as advertised!

On Thu, Sep 8, 2016 at 11:45 AM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 08/09/2016 17:10, Martin Buchholz wrote:
>
>
>
> On Thu, Sep 8, 2016 at 1:06 AM, Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
>
>> On 07/09/2016 22:52, Martin Buchholz wrote:
>>
>> Hi Alan and Chris,
>>>
>>> Here's a bad fix for
>>> https://bugs.openjdk.java.net/browse/JDK-8165643
>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/SecureDi
>>> rectoryStream-non-x86/ <http://cr.openjdk.java.net/%7
>>> Emartin/webrevs/openjdk9/SecureDirectoryStream-non-x86/>
>>>
>> I wonder if we can remove fstatat64_wrapper completely, the reason this
>> code has this is because the support for this function was patchy at the
>> time (some of the platform/versions that the JDK was supported on didn't
>> have it). If you don't want to go that far then that is okay, I just wonder
>> if you could at least avoid have one for i386 and one for 64-bit.
>
>
> It's straightforward to extend my patch to the __i386 case.  It's somewhat
> less straightforward to add configure tests for all the *at functions
> here.  But I only have access to 64-bit Linux at the moment, so I can't do
> proper testing.  It makes sense for someone at Oracle to make more
> extensive changes.  Feel free to do a friendly takeover of this change.
> The total amount of work will end up smallest if JDK-8165620 actually gets
> tackled.
>
> Yeah, the matrix of "supported" build/run platforms makes it harder. Your
> patch is fine for now.
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20160909/5fc3009a/attachment.html>