RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]

[Magnus Ihse Bursie]

On Fri, 2 Feb 2024 07:02:43 GMT, Sam James <duke at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add kludge to BufferedRenderPipe.c for AIX
>
> src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c line 94:
> 
>> 92:         return IOS_UNSUPPORTED_CASE;
>> 93: 
>> 94:     loff_t offset = (loff_t)position;
> 
> Is this `loff_t` for the benefit of `copy_file_range`?

That is how copy_file_range is defined. The cast to off64_t was technically incorrect (but they ended up being the same type).

> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 365:
> 
>> 363: #else
>> 364:     // Make sure we link to the 64-bit version of the functions
>> 365:     my_openat_func = (openat_func*) dlsym(RTLD_DEFAULT, "openat64");
> 
> Explain this part to me, if you wouldn't mind? (Why do we keep the `64` variants?)

I wrote earlier:

> There is one change that merit highlighting: In src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c, I kept the dlsym lookup for openat64, fstatat64 and fdopendir64, on non-BSD OSes (i.e. Linux and AIX), and on AIX, respectively. This seems to me to be the safest choice, as we do not need to know if a lookup of openat would yield a 32-bit or a 64-bit version. (I frankly don't know, but I'm guessing it would yield the 32-bit version.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1476232283
PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1476229335