refactor: change file offset bitwidths in android#5178
Open
dybucc wants to merge 1 commit into
Open
Conversation
Collaborator
|
Some changes occurred in an Android module cc @maurer |
rustbot
added
S-waiting-on-review
stable-nominated
This patch updates the exposed file offset bindings to Android targets. At present, all target triples provide LFS64 types and routines, even though it is only on platforms with a 32-bit ABI that this is required. The Android upstream documentation mentions that these symbols are not really necessary in platforms with a 64-bit ABI [1]. We currently also expose those. Following the trend towards providing a single, 64-bit unsuffixed symbol in the `libc` crate, this patch deprecates all such symbols. The deprecation note advises use of the memory-wise equivalent, unsuffixed types. [1]: https://android.googlesource.com/platform/bionic/+/main/docs/32-bit-abi.md
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. |
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
2 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 all LFS64 symbols under Android targets with a 64-bit ABI. This follows from [1], where the Android upstream documentation mentions that these types are simply aliases in such targets, and from the fact the
libccrate is actively attempting to provide a single, unsuffixed type with a fixed bit-width.The linked document mentions as well that unlike other platforms, one does not require the definition of feature test macros such as
__LARGEFILE_SOURCEor__LARGEFILE64_SOURCEto be present for the LFS64 symbols to both be exposed and aliased.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