android: deprecate file offset types in targets with 64-bit abis#5178
Open
dybucc wants to merge 1 commit into
Open
android: deprecate file offset types in targets with 64-bit abis#5178dybucc wants to merge 1 commit into
dybucc wants to merge 1 commit into
Conversation
Collaborator
|
Some changes occurred in an Android module cc @maurer |
rustbot
added
S-waiting-on-review
stable-nominated
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
dybucc
changed the title
This comment has been minimized.
This comment has been minimized.
tgross35
reviewed
Jun 23, 2026
dybucc
changed the title
Android had LFS64 bindings. This is not necessary. Targets with 32-bit ABIs have it upstream. Targets with 64-bit ABIs don't. This patch deprecates them. This only applies to targets with 64-bit ABIs.
Collaborator
|
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. |
Contributor
Author
|
None. The PR title was wrong. The commit was also wrong. The description is correct. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR deprecates symbols. Affected symbols include LFS64 bindings. Android is the target OS. 64-bit ABI architectures are affected. 32-bit ABI architectures are not.
Android aliases these types. This only applies to 64-bit ABI targets [1.] Anybody using them should be unaffected. A warning should be all they get. 32-bit targets are unchanged.
Sources
Upstream code search yielding results for suffixed variants of LFS64 routines existing as aliases to suffixed variants. Only a few examples are provided because others follow the same pattern.
Upstream code search shows how
ino64_tis defined in terms of its unsuffixed type in the vendored musl. Other libc implementations for targets with a 64-bit ABI follow that the effective bit width of the type is equivalent to that of the unsuffixed type. The "end" type to which all prior type aliases resolve to is a Cunsigned longin 64-bit ABIs and a a Cunsigned long longotherwise. This matches up with the 64-bit fixed width definition in the vendored musl, and thus serves the same aliasing purposes.Upstream code search shows how
flock64has the same definition asflock. All its fields except those that areoff_tare equivalent, and under 64-bit ABIs,off_tis also equivalent tooff64_t.Upstream code search shows how
dirent64has an equivalent definition todirent. Its fields display the same pattern as the above type. Note that search result also contains irrelevant results, and one should look only at those where an actual record is defined. Some of the vendored libc implementations will#defineone in terms of the other, while others will just check for the presence of the__LARGEFILE64_SOURCEfeature test macro. We can safely assume that an internal Android-specific shim is already in charge of defining those when and if needed.Upstream code search shows how
off64_thas an equivalent definition to its unsuffixed variant. This follows the same pattern as the above types. Note how the source files where it is declared in terms of the unsuffixed type correspond to either 64-bit ABI targets, or are conditionally compiled for such platforms.Upstream code search shows how
rlim64_tis defined in terms ofrlim_t.rlimit64then follows with a definition that only varies fromrlimitin whether it usesrlim64_torrlim_tfor its fields.Upstream code search shows how
statfs64has definitions with fields equivalent to those of the unsuffixed type. The latter further uses other type aliases for which sources are also provided, and for which the effective bit width is equivalent once conditionally compiled code resolves in targets with a 64-bit ABI.Upstream code search showing how
statvfs64has some fields which are conditionally defined as being 64-bit wide under the presence of certain feature test macros (or is altogether not defined under certain other macros.) Android requires not that the user#definethese (required in vendored libc implementations,) so one can assume they are#defined in internal shims.Upstream code shows how the
sigset64_ttype is always defined in terms ofsigset_t.Checklist
libc-test/semverhave been updated*LASTor*MAXare included (see #3131)cd libc-test && cargo test --target mytarget); especially relevant for platforms that may not be checked in CI@rustbot label +stable-nominated