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.
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.
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.
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/timevalon 32-bit platforms to avoid the Y2038 issue. This is the default when building on Yocto for armv7, for example. Unfortunatelysuseconds_tis not an alias to a type of the correct width (unliketime_t), so for Glibc make it a private alias oftime_tto 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.