crate: expose `cfg` for general 64-bit `time_t` functionality by dybucc · Pull Request #5411 · rust-lang/libc

dybucc · 2026-08-14T14:00:37Z

Description

This patch adds support for a new cfg for easily toggling support for
64-bit time_t in supported platforms. This really only sets up the any
one of linux_time_bits64, gnu_time_bits64 or uclibc_time64.

The name of the cfg is time64.

Note support for the equivalent flag in musl has not been included
because we already have set-up automatic detection and toggling of the
corresponding cfg under supported targets ¹.

Checklist

Relevant tests in libc-test/semver have been updated
Commit messages permalink to headers for added or changed API
Placeholder or unstable values like *LAST or *MAX have the
standard doc comment
Tested locally (cargo test -p libc-test --target mytarget);
especially relevant for platforms that may not be checked in CI

@rustbot label +stable-nominated

https://github.com/rust-lang/libc/blob/1a8e71f33b1d6ea1e072210e7fc994417bbb2e34/build.rs#L181-L190 ↩

tgross35

Could you also update CI to use this cfg rather than the current glibc/musl cfg? Since this is what we're most likely to ship, we should make sure it works.

View changes since this review

tgross35 · 2026-08-25T08:28:42Z

@@ -190,7 +196,7 @@ fn main() {
    }


This should also set the musl_v1_2 flag, since that's pretty much all it's gating

I don't think I understand. You mention the musl_v1_2 flag, but that
is already set in that particular code block. Further, you also mention
in another review comment that I shouldn't need the time64 flag, so I
don't think there's anything to change in this particular area.

Sorry missed this - I meant that the variables should imply each other e.g. musl_v1_2 = musl && (musl_v1_2 || time64), uclibc_use_time64 |= time64. But don't worry about this, I'm noticing some other things about this file that I'll clean up after merge.

I think that's done now.

rustbot · 2026-08-25T08:31:11Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

dybucc · 2026-08-29T10:00:07Z

I think it's done now. While checking through the CI workflow file, I
noticed that we even though we set the "updated but deprecated"
RUST_LIBC_UNSTABLE_MUSL_V1_2 environment variable for certain targets
¹, we still check for RUSTC_LIBC_UNSTABLE_MUSL_V1_2_3 in build.rs
².

I was wondering what's our stance on that change for stable releases,
and whether we should even set the deprecated environment variable in
CI. It seems wrong.

@rustbot ready

tgross35

Two small things then LGTM

View changes since this review

dybucc · 2026-09-01T14:57:17Z

Wondering if you saw ¹, @tgross35?

@rustbot ready

https://github.com/rust-lang/libc/pull/5411#issuecomment-5461679894 ↩

tgross35 · 2026-09-04T09:31:42Z

I think it's done now. While checking through the CI workflow file, I noticed that we even though we set the "updated but deprecated" RUST_LIBC_UNSTABLE_MUSL_V1_2 environment variable for certain targets 1, we still check for RUSTC_LIBC_UNSTABLE_MUSL_V1_2_3 in build.rs 2.

I was wondering what's our stance on that change for stable releases, and whether we should even set the deprecated environment variable in CI. It seems wrong.

Oh, I did mean to update main.yaml here. Could you do that?

I'm not sure I follow the rest, why do you consider RUST_LIBC_UNSTABLE_MUSL_V1_2 "updated but deprecated"? And what do we need to take a stance on regarding stable releases?

tgross35 · 2026-09-07T08:19:26Z

Could you rebase this once #5508 lands? let musl_v1_2 = ..., let uclibc_time64 = ..., and let gnu32_time64.

tgross35 · 2026-09-07T08:20:00Z

Also please update the commit summary and PR title to mention the name of the config, it doesn't actually show up anywhere except the env form :)

tgross35 · 2026-09-07T08:20:27Z

-    if "gnu" in target_env and target_bits == "32":
-        # Equivalent of _TIME_BITS=64
-        run(cmd, rustflags=f'{rustflags} --cfg=libc_unstable_gnu_time_bits="64"')
-
-    if "musl" in target_env:
-        # Check with breaking changes from musl, including 64-bit time_t on 32-bit
-        run(cmd, rustflags=f"{rustflags} --cfg=libc_unstable_musl_v1_2")
+    if ("gnu" in target_env and target_bits == "32") or "musl" in target_env:
+        # Global toggle for _TIME_BITS=64 on glibc, and musl breaking changes
+        # concerning 64-bit time_t.
+        run(cmd, rustflags=f"{rustflags} --cfg=libc_unstable_time64")


I added uclibc to these checks, so this will need to get updated

View changes since the review

tgross35

Updating status. I think that this merging will be the cutoff for the next release.

View changes since this review

rustbot · 2026-09-09T17:25:35Z

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.

dybucc · 2026-09-10T13:08:01Z

I think it's done now. While checking through the CI workflow file, I
noticed that we even though we set the "updated but deprecated"
RUST_LIBC_UNSTABLE_MUSL_V1_2 environment variable for certain
targets 1, we
still check for RUSTC_LIBC_UNSTABLE_MUSL_V1_2_3 in build.rs
2.

I was wondering what's our stance on that change for stable releases,
and whether we should even set the deprecated environment variable in
CI. It seems wrong.

Oh, I did mean to update main.yaml here. Could you do that?

I'm not sure I follow the rest, why do you consider
RUST_LIBC_UNSTABLE_MUSL_V1_2 "updated but deprecated"? And what do we
need to take a stance on regarding stable releases?

Just updated the workflow file.

I consider RUST_LIBC_UNSTABLE_MUSL_V1_2 deprecated because we phased
out support for those environment variables a while ago in favor of
unstable cfgs. CI sets the cfg when it detects TEST_MUSL_V1_2.

I also consider it updated because #5200 brought with it changes to the
specific musl version for which the cfg gates functionality. Though
RUST_LIBC_UNSTABLE_MUSL_V1_2 has never been supported.

The build script continues to check for RUST_LIBC_UNSTABLE_MUSL_V1_2_3
(note the _3.) I guess this didn't get changed because it only really
continues being supported for backwards-compatibility.

@rustbot ready

Add `cfg` enabling `time64` functionality across all supported targets. This ensures users have a simple entry point to the crate functionality gated behind one of `linux_time_bits64`, `uclibc_time64` and `gnu_time_bits64`. The new `cfg` goes by the name `time64`.

Switch as many uses of other target-specific `cfg`s with the `time64` `cfg` introduced in the prior patch.

- Change indentation of two YAML arrays to consistently appear as nested within the key that corresponds with the array. - Change one inconsistent use of single quotes with double quotes for YAML strings.

Replace use of `RUST_LIBC_UNSTABLE_MUSL_V1_2` with `TEST_MUSL_V1_2` in the PowerPC CI runs. The former is deprecated; The latter is used in CI scripts to set the right unstable `cfg` for functionality gated behind musl's v1.2.

rustbot added S-waiting-on-review stable-nominated This PR should be considered for cherry-pick to libc's stable release branch labels Aug 14, 2026

tgross35 requested changes Aug 25, 2026

View reviewed changes

rustbot added S-waiting-on-author and removed S-waiting-on-review labels Aug 25, 2026

dybucc force-pushed the time64-global-cfg branch from 98e48b9 to 1ab4287 Compare August 29, 2026 06:37