linux(musl): deprecate LFS64 bindings

[dybucc]

Description

This PR removes support for the exposed LFS64 bindings under Linux musl. This follows from the libc crate's attempts at providing a single, unsuffixed type with which to provide 64-bit functionality.

This follows from #5032, where I understood libc was meant to provide a single, unsuffixed type and not necessarily support aliases (much less conditional aliases.) Upstream musl also defines the LFS64 types routines in terms of the unsuffixed types and routines.

This patch ensures we deprecate these types and the whole musl/lfs64 module in favor of using only the unsuffixed types and routines.

Sources

No specific sources are provided. Running the following command with rg in the main worktree of latest musl should yield search results that show the uniform aliasing mentioned above across all header files.

rg -C 15 -s -uu -g "**/*.h" -e "\\b_LARGEFILE64_SOURCE\\b"

Checklist

• Relevant tests in libc-test/semver have been updated
• No placeholder or unstable values like *LAST or *MAX are included (see #3131)
• Tested locally (cd libc-test && cargo test --target mytarget); especially relevant for platforms that may not be checked in CI

[tgross35]

I haven't yet taken a close look here but I think deprecation of *64 types should hold off until we provide a stable way to enable 64-bit time/offset. I don't think users have great recourse for now - until they can get a 64-bit dirent et al. on 32-bit platforms, this deprecation basically encourages splitting imports into 32- and 64-bit, which doesn't really improve anything on its own.

[dybucc]

I've double-checked the changes in this patch with upstream. There really isn't a difference between unsuffixed types and suffixed types.

musl will just provide 64-bit definitions no matter what. I don't quite understand how does this change not solve the issue altogether. All users, no matter their machine word size or memory model, are already using 64-bit file offset types.

The point being, there's no special treatment as there is with time_t.

[xbjfk]

The history of these are a bit convoluted but these should probably be removed in 1.0, for glibc as well.

This is not based on any formal standard, and to my understanding was only added by musl for compatibility as a workaround for nonportable C code that did not use a feature test for these.

In my opinion, LFS types should not be used at all, irrespective of libc. Musl intends to remove all aliases to them, even if _LARGEFILE64_SOURCE is defined [1]. man 7 feature_test_macros also says (emphasis mine):

_LARGEFILE64_SOURCE
Expose definitions for the alternative API specified by the LFS (Large File Summit) as a "transitional extension" to the Single UNIX Specification. (See ⟨http://opengroup.org/platform/lfs.html⟩.) The alternative API consists of a set of new objects (i.e., functions and types) whose names are suffixed with "64" (e.g., off64_t versus off_t, lseek64() versus lseek(), etc.). New programs should not employ this macro; instead _FILE_OFFSET_BITS=64 should be employed.

As @dybucc mentioned, the *64 suffixed types are functionally equivalent to the non-suffixed ones on musl. No matter what you use, you always get large file support, which carried over to this crate - off_t is 64 bit even on 32 bit architectures on musl.

More/misc info below for those interested:

Rich himself has this summary, where he describes the history as well.
https://www.openwall.com/lists/musl/2022/09/26/1

Rich opened an issue on this repo: #2934

Musl commits relating to this: kraj/musl@f0b85fd, kraj/musl@2dd8d5e, kraj/musl@3b94dab, kraj/musl@25e6fee

Google removed LFS64 from Bionic as well (where funnily enough they also talk about this crate): https://www.openwall.com/lists/musl/2022/09/30/8

Oracle removed LFS64 usages in Java: https://bugs.openjdk.org/browse/JDK-8318696

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.