On Fri, 19 Jan 2024 06:47:39 GMT, Sam James <d...@openjdk.org> 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