32-bit Android `ino_t` type definition is incorrect

[tgross35]

See #4216. ino_t is currently a long, but on 32-bit should be a u64.

We probably ideally want a few of the other changes from that PR, such as setting the correct field types, in cases where they are correct.

[robertkirkman]

My personal impression has been that the current content of github.com/rust-lang/libc regarding 32-bit Android is correct, because at least to me, the types used in github.com/rust-lang/libc appear to match the types used inside of the source code of Android:

Inside of 32-bit Android, there is this series of typedefs:

typedef unsigned long __kernel_ulong_t;
typedef __kernel_ulong_t __kernel_ino_t;
typedef __kernel_ino_t __ino_t;
typedef __ino_t ino_t;

followed by this variable declaration:

unsigned long long st_ino;

https://cs.android.com/android/platform/superproject/+/android-15.0.0_r1:bionic/libc/kernel/uapi/asm-generic/posix_types.h;l=15
https://cs.android.com/android/platform/superproject/+/android-15.0.0_r1:bionic/libc/include/sys/types.h;l=70
https://cs.android.com/android/platform/superproject/+/android-15.0.0_r1:bionic/libc/include/sys/stat.h;l=98

From that, it can be seen that in 32-bit Android, ino_t is the same type as unsigned long, and st_ino is a variable of type unsigned long long.

In github.com/rust-lang/libc, there is this content for 32-bit Android:

libc/src/unix/linux_like/android/mod.rs

Line 37 in 9cf1a1c

pub type ino_t = c_ulong;

libc/src/unix/linux_like/android/b32/mod.rs

Line 70 in 9cf1a1c

pub st_ino: c_ulonglong,

From that, it can be seen that in github.com/rust-lang/libc, for 32-bit Android, ino_t is currently mapped to c_ulong, and st_ino is currently declared as c_ulonglong.

If, in Rust, c_ulong corresponds to the type in C named unsigned long, and c_ulonglong corresponds to the type in C named unsigned long long, then it seems, at least to me, like the current content of github.com/rust-lang/libc regarding this type and this variable in 32-bit Android is correct and does not need to be changed.

However, I don't know very much about Rust and how Rust works, so it is possible that I could be misunderstanding some factor here, or miscalculating some part of my analysis.

[tgross35]

Thank you for looking into this! That all sounds correct to me. In that case I guess there isn't anything strictly needed to do here: it would be nice to make some changes so the struct field types more closely match Android sources, but it sounds like there aren't any actual bugs to resolve.