I maintain a repo with builds of GHC for the musl C standard library and I encountered a subtle bug of this library that affects GHC under 32-bit architectures with musl.
In 32-bit architectures, there was a transition where the C type time_t was redefined to be 64-bit in order to address the Y2038 problem. The way this was handled by musl was by introducing new versions of all affected syscalls that work with 64-bit time_t (e.g. utimensat_time64 is like utimensat but with 64-bit time_t). In addition, a redirect was introduced to create an alias of the new versions of these functions under the old name (e.g. here's the redirection for utimensat).
The problem is that this redirection is defined as a C macro in a C header file and as such, it does not get picked by GHC when the foreign function import is done via ccall, but works just fine when capi is used. So this PR changes utimensat to be imported with capi, which should be a fairly uncontroversial change.
Rufflewind
commented
1 year ago
I maintain a repo with builds of GHC for the musl C standard library and I encountered a subtle bug of this library that affects GHC under 32-bit architectures with musl.
In 32-bit architectures, there was a transition where the C type
time_twas redefined to be 64-bit in order to address the Y2038 problem. The way this was handled by musl was by introducing new versions of all affected syscalls that work with 64-bittime_t(e.g.utimensat_time64is likeutimensatbut with 64-bittime_t). In addition, a redirect was introduced to create an alias of the new versions of these functions under the old name (e.g. here's the redirection forutimensat).The problem is that this redirection is defined as a C macro in a C header file and as such, it does not get picked by GHC when the foreign function import is done via
ccall, but works just fine whencapiis used. So this PR changesutimensatto be imported withcapi, which should be a fairly uncontroversial change.