-
Notifications
You must be signed in to change notification settings - Fork 195
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
base: main
Are you sure you want to change the base?
Support for building with 64-bit time_t/off_t on 32-bit platforms #1395
Conversation
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.
@swift-ci test |
@@ -963,6 +967,12 @@ extension _FileManagerImpl { | |||
#endif | |||
} | |||
|
|||
#if canImport(Glibc) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
.
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. Unfortunatelysuseconds_t
is not an alias to a type of the correct width (unliketime_t
), so for Glibc make it a private alias oftime_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.