android: use proper types for dirent.d_ino, dirent.d_off, stat.st_mode and stat64.st_mode

[thunder-coding]

This bug was noticed in https://github.com/termux/termux-packages/pull/22609

Description

Fixes types for dirent.d_ino, dirent.d_off, stat.st_mode and stat64.st_mode on Android.

The hardcoded types are incorrect and this PR changes them to how they are declared for Linux. Also fixes the incorrect type errors in https://github.com/termux/termux-packages/pull/22609, where I found the bug (The builds are still failing due to missing posix_spawn* support here, but that's a different issue.)

~~This patch should likely also be backported to 0.2.x release, I have the patchset already applied on my other branch. Will link another PR soon.~~ It seems that this patch applies cleanly to libc-0.2 branch, I was backporting to an older release earlier. @rustbot label stable-nominated should be it according to CONTRIBUTING.md

Sources

mode_t: mode_t is defined as unsigned int on 64-bit android platforms: https://android.googlesource.com/platform/prebuilts/ndk/+/dev/platform/sysroot/usr/include/sys/types.h#64 https://android.googlesource.com/platform/prebuilts/ndk/+/dev/platform/sysroot/usr/include/asm-generic/posix_types.h#18 and is defined as unsigned short on 32-bit platforms: https://android.googlesource.com/platform/prebuilts/ndk/+/dev/platform/sysroot/usr/include/i686-linux-android/asm/posix_types_32.h#9 https://android.googlesource.com/platform/prebuilts/ndk/+/dev/platform/sysroot/usr/include/arm-linux-androideabi/asm/posix_types.h#9

off_t: https://android.googlesource.com/platform/bionic/+/main/docs/32-bit-abi.md mentions that off_t is i32 on 32-bit and i64 on 64-bit

ino_t: https://android.googlesource.com/platform/prebuilts/ndk/+/dev/platform/sysroot/usr/include/dirent.h#64 https://android.googlesource.com/platform/prebuilts/ndk/+/dev/platform/sysroot/usr/include/sys/types.h#70 https://android.googlesource.com/platform/prebuilts/ndk/+/dev/platform/sysroot/usr/include/asm-generic/posix_types.h#14 Due to "historic accident", although ino_t is unsigned long on all platforms, the actual type used is unsigned long on 64-bit and uint64_t on 32-bit. I think we should just declare ino_t to be of type unsigned long on 64-bit and uint64_t on 32-bit as that's how code using these types is supposed to be used.

Checklist

• [ ] Relevant tests in libc-test/semver have been updated
• [X] 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 I tried building the tests locally, it seems like the tests are already broken for Android. But I was able to fix some of the issues in https://github.com/termux/termux-packages/pull/22609

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @tgross35 (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[tgross35]

Thanks for the detailed sources. Is the following delta accurate?

• unsigned int -> unsigned short (32 -> 16) for mode_t on 32 bit
• unsigned long -> uint64_t (32 -> 64) for ino_t on 32 bit
• long -> int32_t (32 -> 32, nop) for off_t on 32 bit

These issues seem reasonably severe so I am surprised it has not been noticed before (@maurer do you know of anything?). I guess the other fields at least keep the relevant fields here correctly aligned?

~This patch should likely also be backported to 0.2.x release, I have the patchset already applied on my other branch. Will link another PR soon.~ It seems that this patch applies cleanly to libc-0.2 branch, I was backporting to an older release earlier. @rustbot label stable-nominated should be it according to CONTRIBUTING.md

For reference, the command can't be in backticks :)

@rustbot label stable-nominated

[thunder-coding]

You can't reset ino_t to be u64 because it got represented as u64 in dirent - it's used in other places, e.g. FTSENT where it must have its original value. While libc doesn't bind this struct, other crates do, and they use libc's ino_t type assuming that it matches the C variant.

Oh yeah, I didn't look into other uses of ino_t in FTSENT. I don't think I am capable of taking this PR further. This is just way too complicated for me. Feel free to take over this

[tgross35]

@rustbot author

There is no rush for anything here, so great if you get a chance to update this and no worries if not. It may also be possible to split this into smaller PRs, that is an option as well if you are able.

[robertkirkman]

Unfortunately, it turned out that this PR did not successfully work at run-time in a real-world 32-bit Android situation:

• https://github.com/termux/termux-packages/issues/24741

My personal belief is that in this case, the original errors (in the Fish project) should actually be considered the responsibility of the Fish side of the code, and that the correct location to apply patches is in the Fish code, so if, for example, the Fish project does not officially intend to support Android, then termux-packages should apply downstream patches to the Fish-specific code, not to the rust-lang/libc cargo crate.

[tgross35]

Since this needs work but is inactive, I'm going to close this. I created an issue for the ino_t change here https://github.com/rust-lang/libc/issues/4801.

Please feel free to reopen if you are able to make the needed updates.