Use CApiFFI for syscalls that break with glibc's handling of 64-bit time_t

[iliastsi]

As part of the effort to support 64-bit time_t on 32-bit platforms, glibc uses macros to define functions like clock_gettime(), gettimeofday(), mktime(), localtime() etc. This breaks unix-time which uses the ccall calling convention.

As an example, the following code breaks on a 32-bit system with 64-bit time_t:

import Data.UnixTime

main = getUnixTime >>= print

output:

UnixTime {utSeconds = 2274169716966502, utMicroSeconds = 0}

Here are some related fixes on other Haskell libraries:

• Use capi for syscalls that break under musl's handling of 64-bit time_t haskell/directory#145
• Use capi for syscalls that break under musl's handling of 64-bit time_t haskell/time#225
• Use capi for syscalls that break under musl's handling of 64-bit time_t haskell/unix#252

[kazu-yamamoto]

I don't have 32bit machines anymore.
Could you create a PR?

[iliastsi]

Hi @kazu-yamamoto, I can send a PR yes.

Looking at the code, I also noticed that utMicroSeconds is defined as Int32 (see https://github.com/kazu-yamamoto/unix-time/blob/a0e38a4a9688a0ac340e0069478a7e9d5210ac3b/Data/UnixTime/Types.hsc#L37C5-L37C19), but tv_usec from struct timeval is of type suseconds_t, which on 64-bit systems is 8 bytes long.

This means that unix-time is broken on big endian systems, and always sets utMicroSeconds to 0.

One solutions would be to change utMicroSeconds to be of type CSUSeconds instead (https://hackage.haskell.org/package/base-4.20.0.0/docs/Foreign-C-Types.html#t:CSUSeconds), but this will change the API for this package.

Another solution is to peek the value as CSUSeconds and then convert it to Int32 (given that tv_usec is in the [0, 999,999] range). Let me know how you want to handle this and I can include it in this PR as welll.

[kazu-yamamoto]

Nice catch!
To maintain backward compatibility, I like the latter approach.
PR is highly welcome!