android: deprecate file offset types in targets with 64-bit abis#5178
android: deprecate file offset types in targets with 64-bit abis#5178dybucc wants to merge 1 commit into
Conversation
|
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.
dybucc
changed the title
This comment has been minimized.
This comment has been minimized.
|
None. The PR title was wrong. The commit was also wrong. The description is correct. |
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.
|
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. |
|
☔ The latest upstream changes (possibly #5233) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Since this is mostly deprecation-related, holding off @rustbot blocked |
|
(https://snoozeth.is/NC0lVRQ8J6w) I will wait until Fri, 04 Sep 2026 04:36:38 UTC and then add label S-waiting-on-review and remove label S-blocked. @rustbot claim. |
4 participants
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