On Fri, 19 Jan 2024 06:47:39 GMT, Sam James <[email protected]> wrote:
>> The LFS64 symbols provided by glibc are not part of any standard and were
>> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5).
>> This commit replaces the usage of LFS64 symbols with their regular
>> counterparts and defines -D_FILE_OFFSET_BITS=64, ensuring that functions
>> will always act as their -64 variants on glibc.
>
> Sam James has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add message for assert
>
> Not all C++ stds implement it w/o.
Consider (perhaps in a separate PR) forbidding the use of the xxx64 functions,
using FORBID_C_FUNCTION (from compilerWarnings.hpp &etc). I think it would be
done in globalDefinitions_gcc.hpp, and probably conditional on
_LARGEFILE64_SOURCE.
src/hotspot/os/linux/os_linux.cpp line 4252:
> 4250: // otherwise, returns -1 that implies an error
> 4251: jlong os::Linux::sendfile(int out_fd, int in_fd, jlong* offset, jlong
> count) {
> 4252: return ::sendfile64(out_fd, in_fd, (off_t*)offset, (size_t)count);
Why is this continuing to use sendfile64, rather than sendfile?
src/hotspot/os/linux/os_linux.cpp line 4936:
> 4934: {
> 4935: struct stat buf64;
> 4936: int ret = ::fstat(fd, &buf64);
Consider s/buf64/buf/. The 64 suffix looks rather odd now.
-------------
PR Review: https://git.openjdk.org/jdk/pull/16329#pullrequestreview-1832057351
PR Review Comment: https://git.openjdk.org/jdk/pull/16329#discussion_r1458712646
PR Review Comment: https://git.openjdk.org/jdk/pull/16329#discussion_r1458717682
