windows(gnu): link to 32-bit time routines in x86 and add test by dybucc · Pull Request #5059 · rust-lang/libc

dybucc · 2026-04-14T17:21:42Z

Description

Until #5032, whenever libc was running under Windows x86 with GNU, the default
bit-width of time_t values was 32-bits. This doesn't quite align with the defaults in MSVC and
mingw, but that's been addressed in that PR.

This PR is a quick patch for stable, as the changes in #5032 are not
backwards-compatible. It separates the routines that under Windows use time_t values and changes
their link-time symbols to the 32-bit variants exposed in both MSVC and mingw, for the affected
target platform/environment.

It also adds a test, akin to the one in #5032, that should ensure the correct
bit-widths are in use for both the types and the linked routine symbols.

Note that if both #5062 and this PR are to be merged, it's preferable to merge first #5062, as this
PR will then incorporate support for the cfg introduced in that PR.

Sources

None. If any, the same as #5032 as this stems from it.

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

@rustbot label +stable-nominated

tgross35 · 2026-06-26T06:52:27Z

+    assert_ne!(time_values[0], 123);
+    assert_eq!(time_values[1], 456);


Suggested comment based on #5032 (comment):

If only the first array value is written, libc's time_t is accurate for what the function time expects. If both array values wind up overwritten, we are probably linking a version of time that expects 64-bit time_t while our time_t is only 32 bits.

Also can you confirm that this fails with the current version?

View changes since the review

I can. CI doesn't catch this because we skip over time_t on Windows. I removed that in #5062.

tgross35 · 2026-06-26T06:53:31Z

+    // Under Windows x86 with GNU, `time_t` is still 32-bit wide on stable, so
+    // these routines have to link with their 32-bit variants.
+    cfg_if! {
+        if #[cfg(all(target_arch = "x86", target_env = "gnu", not(gnu_time_bits64)))] {


Move anything gnu_time_bits64 bit to #5062, since it's not getting fully tested here and that PR doesn't currently do anything on its own.

View changes since the review

I meant only the not(gnu_time_bits64) bit of the config, given the test failures and lack of it being tested. The link fixes are fine, that should be in this PR because it's a standalone fix.

Though if it's easier for you at this point to roll the two PRs together, that's fine too

Reverted and done. This PR should then be merged first. I'll solve the conflicts in #5062 then.

EDIT: No good. Reverted again. The linking issues remain solved in this PR. The other one will have to add the condition to the predicate once this one gets merged.

rustbot · 2026-06-26T06:53:37Z

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

rustbot · 2026-06-26T09:40: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.

tgross35

One nit and history cleanup then LGTM

View changes since this review

Link to the correct routines in Windows x86 GNU. These were not linked before. They expected a 64-bit `time_t`. This is not the bit width exposed in `libc` for `time_t` in that target triple.

tgross35 · 2026-06-26T17:17:59Z

Question: why doesn't this cause the function pointer comparison tests to fail on win32-gnu?

dybucc · 2026-06-27T10:08:14Z

Question: why doesn't this cause the function pointer comparison tests to fail on win32-gnu?

Function pointer checks are skipped on Windows [1]. I've tried to look into this. I haven't found the reason why stuff is failing. The decorated names in MSVC seem to use cdecl but the unresolved errors to all exposed routines also happen in x86_64. I've experimented adding cdecl under x86. This does not seem to work. Function pointer checks still fail in x86_64 when they shouldn't. This includes non-time_t routines. There's no documentation on the linking of decorated names in MSVC either.

tgross35 · 2026-06-27T19:51:41Z

Only on MSVC or on GNU as well? We could at least limit the skips if it's the former.

Calling convention shouldn't affect the function pointer checks regarding address mismatches. It would be nice if we could check calling convention in ctest somehow but I don't believe those mismatches show up anywhere.

You might get a hint if you make a Rust library where you call a libc symbol and a C library where you call the same symbol, then llvm-nm them if there's a mismatch in the undefined symbols list. But I don't think it's worth digging into too much.

tgross35 · 2026-06-27T19:52:01Z

Mind just opening a new issue with your findings so we don't lose this?

dybucc · 2026-06-28T08:29:13Z

It happens on both MSVC and GNU. Just opened the issue.

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

This comment has been minimized.

Sign in to view

dybucc mentioned this pull request Apr 14, 2026

Deprecate windows time64_t #5032

Open

3 tasks

dybucc force-pushed the fix-time32-windows-x86-gnu branch 2 times, most recently from 9a434dd to c8cb7bc Compare April 14, 2026 17:31

dybucc mentioned this pull request Apr 16, 2026

windows: expose cfg for 64-bit time_t #5062

Open

3 tasks

dybucc force-pushed the fix-time32-windows-x86-gnu branch 2 times, most recently from 5a75a87 to a5c7202 Compare April 18, 2026 06:40

This comment has been minimized.

Sign in to view

dybucc force-pushed the fix-time32-windows-x86-gnu branch 2 times, most recently from 0021301 to 4e83e2d Compare April 18, 2026 07:31

dybucc force-pushed the fix-time32-windows-x86-gnu branch from 4e83e2d to 8c5047b Compare April 27, 2026 13:53

This comment has been minimized.

Sign in to view

dybucc force-pushed the fix-time32-windows-x86-gnu branch from 8c5047b to 320bd3c Compare April 28, 2026 15:35

This comment has been minimized.

Sign in to view

dybucc force-pushed the fix-time32-windows-x86-gnu branch from 320bd3c to f858022 Compare April 29, 2026 13:41

This comment has been minimized.

Sign in to view

dybucc force-pushed the fix-time32-windows-x86-gnu branch from f858022 to 2bd4191 Compare May 2, 2026 07:34

This comment has been minimized.

Sign in to view

dybucc force-pushed the fix-time32-windows-x86-gnu branch from 2bd4191 to cdbd6e6 Compare May 5, 2026 12:47

This comment has been minimized.

Sign in to view

dybucc force-pushed the fix-time32-windows-x86-gnu branch from cdbd6e6 to b7c9250 Compare May 6, 2026 06:56

This comment has been minimized.

Sign in to view

dybucc force-pushed the fix-time32-windows-x86-gnu branch from b7c9250 to 0ef0992 Compare May 7, 2026 14:36

This comment has been minimized.

Sign in to view

dybucc force-pushed the fix-time32-windows-x86-gnu branch from 0ef0992 to 61d8568 Compare May 13, 2026 07:01

This comment has been minimized.

Sign in to view

dybucc force-pushed the fix-time32-windows-x86-gnu branch from 61d8568 to f1fd3c7 Compare May 14, 2026 07:00

This comment has been minimized.

Sign in to view

dybucc force-pushed the fix-time32-windows-x86-gnu branch from ebdef8a to 8b5714c Compare June 25, 2026 10:22

rustbot added S-waiting-on-review and removed S-blocked labels Jun 25, 2026

tgross35 requested changes Jun 26, 2026

View reviewed changes

rustbot removed the S-waiting-on-review label Jun 26, 2026

rustbot added the S-waiting-on-author label Jun 26, 2026

dybucc force-pushed the fix-time32-windows-x86-gnu branch from 8b5714c to b0393bb Compare June 26, 2026 08:01

This comment has been minimized.

Sign in to view

dybucc force-pushed the fix-time32-windows-x86-gnu branch from b0393bb to 875f211 Compare June 26, 2026 08:05

dybucc changed the title ~~windows(gnu): link correct 32-bit time_t functions~~ windows(gnu): add test on to ensure bit width of time_t Jun 26, 2026

dybucc force-pushed the fix-time32-windows-x86-gnu branch from 875f211 to a9ee123 Compare June 26, 2026 09:15

This comment has been minimized.

Sign in to view

dybucc force-pushed the fix-time32-windows-x86-gnu branch 3 times, most recently from 3dcc67c to 9bfedc2 Compare June 26, 2026 09:40

tgross35 approved these changes Jun 26, 2026

View reviewed changes

Comment thread libc-test/tests/windows_time.rs Outdated

windows(gnu): link to correct 32-bit time routines

c5d3c12

Link to the correct routines in Windows x86 GNU. These were not linked before. They expected a 64-bit `time_t`. This is not the bit width exposed in `libc` for `time_t` in that target triple.

dybucc force-pushed the fix-time32-windows-x86-gnu branch from a07e2c5 to c5d3c12 Compare June 26, 2026 15:09

dybucc changed the title ~~windows(gnu): add test on to ensure bit width of time_t~~ windows(gnu): link to 32-bit time routines in x86 and add test Jun 26, 2026

tgross35 added this pull request to the merge queue Jun 26, 2026

Merged via the queue into rust-lang:main with commit 5bbfc84 Jun 26, 2026
54 checks passed

tgross35 mentioned this pull request Jun 28, 2026

Windows MSVC/GNU function pointer check issues #5227

Open

		assert_ne!(time_values[0], 123);
		assert_eq!(time_values[1], 456);

Uh oh!

Conversation

dybucc commented Apr 14, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Sources

Checklist

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

Uh oh!

tgross35 Jun 26, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dybucc Jun 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tgross35 Jun 26, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tgross35 Jun 26, 2026

Choose a reason for hiding this comment

Uh oh!

dybucc Jun 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rustbot commented Jun 26, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

rustbot commented Jun 26, 2026

Uh oh!

tgross35 left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tgross35 commented Jun 26, 2026

Uh oh!

Uh oh!

dybucc commented Jun 27, 2026

Uh oh!

tgross35 commented Jun 27, 2026

Uh oh!

tgross35 commented Jun 27, 2026

Uh oh!

dybucc commented Jun 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

dybucc commented Apr 14, 2026 •

edited by rustbot

Loading

tgross35 Jun 26, 2026 •

edited by rustbot

Loading

dybucc Jun 26, 2026 •

edited

Loading

tgross35 Jun 26, 2026 •

edited by rustbot

Loading

dybucc Jun 26, 2026 •

edited

Loading

tgross35 left a comment •

edited by rustbot

Loading