musl: introduce musl_stat_timespec cfg for struct stat

[heiher]

Description

Some musl targets use out-of-line timespec fields in struct stat. This property is independent of the musl_v1_2_3 switch.

Add a new musl_stat_timespec cfg and use it to control the presence of inline time fields in musl struct stat definitions, avoiding incorrect API assumptions based on musl version alone.

Sources

• https://github.com/kraj/musl/tree/v1.2.5

Checklist

• Relevant tests in libc-test/semver have been updated
• 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

[JohnTitor]

The key idea sounds good to me, @tgross35 any thoughts on this? I haven't catched up the time64 change deeply and would like to hear your views.

[tgross35]

Thanks for the fix, sorry that this broke.

Quite honestly I'm feeling like we should just delete the timespec fields and leave st_atime/st_atime_nsec (et. al.) with a comment explaining why we don't exactly match musl source, i.e. more or less revert 55fa65b. Musl allows using the st_atime names via macros https://github.com/kraj/musl/blob/ff441c9ddfefbb94e5881ddd5112b24a944dc36c/include/sys/stat.h#L32C18-L34 so we'd just have a mismatch on the _nsec fields which I think is fine. I'm assuming musl keeps _nsec a bit more hidden since they're not part of posix https://pubs.opengroup.org/onlinepubs/009695299/basedefs/sys/stat.h.html.

That's also nicer for our users who won't need to do a different config for musl and glibc.

Cc @xbjfk for your thoughts as you authored the commit in question.

[xbjfk]

I would personally push for using timespec to:

• Closer match the libc source
• Be POSIX correct and match the correct C usage / docs / man pages.
• Have more compatibility with other architectures (hermit, AIX and hurd are already)
• Make struct definitions easier to read (especially with bi-endian architectures)
• We can remove a lot of test skips.

I personally think the best path forward would be to revert 55fa65b so that people can try the new experimental musl with less breaking changes (and fixing loongarch) and reintroduce the name change without a feature gate for all platforms in the 1.0 branch only for the reasons listed above (virtually every UNIX platform supported by libc uses timespec).

IIRC this was changed with time64 changes the because having conditional definitions for the padding was a bit unwieldy.

Will look into making a PR for this.

[Gelbpunkt]

Quite honestly I'm feeling like we should just delete the timespec fields and leave st_atime/st_atime_nsec (et. al.) with a comment explaining why we don't exactly match musl source, i.e. more or less revert 55fa65b. Musl allows using the st_atime names via macros https://github.com/kraj/musl/blob/ff441c9ddfefbb94e5881ddd5112b24a944dc36c/include/sys/stat.h#L32C18-L34 so we'd just have a mismatch on the _nsec fields which I think is fine. I'm assuming musl keeps _nsec a bit more hidden since they're not part of posix https://pubs.opengroup.org/onlinepubs/009695299/basedefs/sys/stat.h.html.

That's also nicer for our users who won't need to do a different config for musl and glibc.

Cc @xbjfk for your thoughts as you authored the commit in question.

I think the problem is that we'd like to match the musl headers, which means that ideally, we should be using timespec, but we cannot use it unconditionally yet due to the minimum musl version requirements. The current behavior is inconsistent - it is different depending on the target architecture and the environment variables set, which means that it's near impossible for a crate that depends on libc to conditionally compile code. If it were as simple as #[cfg(target_env = "musl")], IMHO it would be acceptable, but the inconsistency is the key problem. Therefore
I'm generally in favor of reverting the commit in question on 0.2, but I think it should be left as-is on 1.0 and support for older musl versions should not be considered for the sake of simplicity.

This basically broke Rust entirely for us in Alpine Linux on loongarch64 (which unconditionally has timespec) and as soon as we need to set RUST_LIBC_UNSTABLE_MUSL_V1_2_3=1 to make use of statx, we see basically all architectures fail to compile as well. The musl version mess (apologies for the choice of words) in libc 0.2 is just not navigatable for the Rust ecosystem.

edit: Side note, we'd like to set RUST_LIBC_UNSTABLE_MUSL_V1_2_3=1 globally on our builders, but for obvious reasons we currently cannot do it.

[xbjfk]

Yeah, that's generally what I would support doing. I think #4958 does exactly that, but I'll take a closer look. It definitely would be nice to avoid breaking changes even behind the unstable flag (and fix loongarch of course).

Also note that almost every platform I've taken a look at uses timespec, so we should migrate all platforms for 1.0, for consistency + correct behavior.

[heiher]

Resolved by #4958

[tgross35]

More discussion on possible follow up at #4965.