Skip to content

POSIX: change struct stat/stat64 times to timespec - #5069

Open
xbjfk wants to merge 15 commits into
rust-lang:mainfrom
xbjfk:stat-timespec
Open

xbjfk wants to merge 15 commits into
rust-lang:mainfrom
xbjfk:stat-timespec

Conversation

@xbjfk

@xbjfk xbjfk commented Apr 21, 2026 •

Copy link
Copy Markdown
Contributor

Why?

The primary reason for this change is that this is the correct POSIX specification, and using _nsec etc. may be considered deprecated - meaning this better follows the C struct definition more closely as well as C man pages / docs. Additionally, this makes the struct easier to read, and removes the need for many test skips, and brings all established platforms in parity with Hurd etc. which already use the new declaration in this crate. More discussion in #4965

Description

Since this was evidently a problem when doing musl changes and v1 being in alpha, it's time to rip the band aid off and do it.

Of course, there are a couple unsolved questions:

Also, solid and qurt do not have nsec at all. NTO and VxWorks have already migrated.

Sources

In each relevant commit.

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

As discussed in / Fixes: #4965

@rustbot

rustbot commented Apr 21, 2026

Copy link
Copy Markdown
Collaborator

Some changes occurred in a solarish module

cc @jclulow, @pfmooney

Some changes occurred in an Android module

cc @maurer

Some changes occurred in an OpenBSD module

cc @semarie

Some changes occurred in a NetBSD-like module

cc @semarie

@xbjfk

xbjfk commented Apr 21, 2026

Copy link
Copy Markdown
Contributor Author

Hmm, since freebsd11 no longer depends on c_long, the prelude is no longer necessary - but it feels wrong to remove.

@rustbot

rustbot commented Apr 26, 2026

Copy link
Copy Markdown
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.

@tgross35 tgross35 added this to the 1.0 milestone Jun 19, 2026
@tgross35 tgross35 added the stable-declined This change is breaking, difficult to backport, low priority, or otherwise not relevant for 0.2 label Jun 19, 2026

@tgross35 tgross35 left a comment •

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All of this looks pretty good to me, but I'm going to hold off on merging for a bit. We have a handful of changes coming down the pipeline that are doing 64-bit time conversions, which this will conflict with, and it will be easier to apply this after all of that rather than before. (Not on its own, but taking stable backports into consideration).

Would you mind adding the reasoning (posix spec alignment) to the PR description? For any drive by readers.

View changes since this review

@tgross35

Copy link
Copy Markdown
Member

For some time to get time64 changes in,
@SnoozeThis 2 months

@SnoozeThis

This comment was marked as outdated.

@tgross35

This comment was marked as outdated.

@tgross35

Copy link
Copy Markdown
Member

Come on alarm clock...
@rustbot blocked
@SnoozeThis wait 2 months -> remove label S-blocked, add label S-waiting-on-review

@SnoozeThis

Copy link
Copy Markdown

(https://snoozeth.is/WTvxKr50tBM) I will wait until Wed, 19 Aug 2026 07:45:28 UTC and then add label S-waiting-on-review and remove label S-blocked.

@rustbot claim.

@xbjfk

xbjfk commented Jun 20, 2026

Copy link
Copy Markdown
Contributor Author

Would you mind adding the reasoning (posix spec alignment) to the PR description? For any drive by readers.

Done - I made a nice and prominent "Why?" section at the top :)

@tgross35 tgross35 mentioned this pull request Jun 22, 2026
2 of 3 tasks
@rustbot

This comment has been minimized.

@maurer maurer left a comment •

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@SnoozeThis

Copy link
Copy Markdown

Resolved.

@rustbot label +S-waiting-on-review -S-blocked. @rustbot release-assignment.

@tgross35 tgross35 left a comment •

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would you be up for merging these definitions in a commit prior to the timespec change? Similar to what fc8a345, 72f0135, and others did, that would reduce the surface area quite a bit.

I've been meaning to do this before replying on this PR but still haven't yet, so figured I'd at least let you know that's what it's blocked on in case you have the time to pick it up.

View changes since this review

@xbjfk

xbjfk commented Oct 5, 2026

Copy link
Copy Markdown
Contributor Author

I rebased and fixed conflicts, will now move to src/new

@rustbot

rustbot commented Oct 5, 2026

Copy link
Copy Markdown
Collaborator

⚠️ Warning ⚠️

  • There are links that are not permanent in the commit message of the following commits. Please use a permalink instead.

xbjfk added 10 commits October 5, 2026 06:20
@xbjfk

xbjfk commented Oct 5, 2026

Copy link
Copy Markdown
Contributor Author

@tgross35 Working on this now, but one question: how important are argument names? I see currently a lot don't match the headers/man pages, but I want to know for sure before I go too deep one way or another.

I made a topic on Zulip as well with more details: #t-libs/crates > Policy for function argument names in libc?

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

What time fields should struct stat have?

5 participants