close
Skip to content

fix: fix differing bitwidth types/routines under Windows x86 GNU#5059

Open
dybucc wants to merge 1 commit intorust-lang:mainfrom
dybucc:fix-time32-windows-x86-gnu
Open

fix: fix differing bitwidth types/routines under Windows x86 GNU#5059
dybucc wants to merge 1 commit intorust-lang:mainfrom
dybucc:fix-time32-windows-x86-gnu

Conversation

@dybucc
Copy link
Copy Markdown
Contributor

@dybucc dybucc commented Apr 14, 2026

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

@rustbot 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
@rustbot

This comment has been minimized.

@dybucc dybucc mentioned this pull request Apr 14, 2026
3 tasks
@dybucc 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 dybucc force-pushed the fix-time32-windows-x86-gnu branch 2 times, most recently from 5a75a87 to a5c7202 Compare April 18, 2026 06:40
@rustbot

This comment has been minimized.

@dybucc 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 dybucc force-pushed the fix-time32-windows-x86-gnu branch from 4e83e2d to 8c5047b Compare April 27, 2026 13:53
@rustbot

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

Until rust-lang#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
rust-lang#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 rust-lang#5032, that should
ensure the correct bit-widths are in use for both the types and the
linked routine symbols.
@dybucc dybucc force-pushed the fix-time32-windows-x86-gnu branch from f858022 to 2bd4191 Compare May 2, 2026 07:34
@rustbot
Copy link
Copy Markdown
Collaborator

rustbot commented May 2, 2026

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.

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

Labels

S-waiting-on-review stable-nominated This PR should be considered for cherry-pick to libc's stable release branch

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants