Skip to content

Support for building with 64-bit time_t/off_t on 32-bit platforms #1395

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

lhoward
Copy link

@lhoward lhoward commented Jul 1, 2025

It is good practice to build with 64-bit time_t/timeval on 32-bit platforms to avoid the Y2038 issue. This is the default when building on Yocto for armv7, for example. Unfortunately suseconds_t is not an alias to a type of the correct width (unlike time_t), so for Glibc make it a private alias of time_t to fix the build.

It is also possible to build with 64-bit file offsets on 32-bit platforms such as armv7, and indeed this is the default for some build environments such as Yocto. Use fsblkcnt_t, which is an alias to a type of the correct width, when computing blockSize.

lhoward added 2 commits July 1, 2025 14:22
It is possible to build with 64-bit file offsets on 32-bit platforms such as
armv7, and indeed this is the default for some build environments such as
Yocto. Use fsblkcnt_t, which is an alias to a type of the correct width, when
computing blockSize.
It is good practice to build with 64-bit time_t/timeval on 32-bit platforms to
avoid the Y2038 issue. This is the default when building on Yocto for armv7,
for example. Unfortunately suseconds_t is not an alias to a type of the correct
width (unlike time_t), so for Glibc make it a private alias of time_t to fix
the build.
@MaxDesiatov
Copy link
Contributor

@swift-ci test

@MaxDesiatov MaxDesiatov requested a review from jmschonfeld July 2, 2025 09:18
@@ -963,6 +967,12 @@ extension _FileManagerImpl {
#endif
}

#if canImport(Glibc)
Copy link
Contributor

@jmschonfeld jmschonfeld Jul 2, 2025

Choose a reason for hiding this comment

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

Is there some #define that's enabled when building with 64bit values on a 32 bit platform that we should check before doing this? IIUC this would allow it to build when that is enabled, but would cause the build to fail in the situations where the build currently passes (the setting is disabled when building for 32 bit). I'm not sure if Swift has any Glibc-based 32 bit platforms that are officially supported but it might make sense to mitigate that risk by conditionalizing this to not just canImport(Glibc) but the specific scenario where it currently fails to build

Copy link
Author

Choose a reason for hiding this comment

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

The change doesn't break 32-bit timestamps on 32-bit platforms. We have verified this as we actually ended up backing out enabling 64-bit timestamps on 32-bit platforms in our build pending some other package updates.

If you're concerned about FreeBSD, maybe we also add an os(Linux) check.

There is a C #define for 64-bit timestamps (well, for whether time_t is wide on 32-bits in the current compilation unit) but that's not going to be visible in Swift.

Copy link
Author

Choose a reason for hiding this comment

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

Of course in a C header we could conditionally define a type of the appropriate width conditional on _TIME_BITS but, that's describing time_t.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants