Fix CTimeVal definition for platforms where time_t isn't CLong#318
Fix CTimeVal definition for platforms where time_t isn't CLong#318Bodigrim merged 1 commit intohaskell:masterfrom
Conversation
|
@liskin could you please rebase? Hopefully CI will get better. |
One such platform is Debian unstable armhf, which is in the process of transitioning to 64-bit time_t: https://wiki.debian.org/ReleaseGoals/64bit-time On that platform (as well as any other glibc/musl platform), however, CTimeVal isn't used for anything at all because there are #ifdefs that prefer using `utimensat` which takes CTimeSpec instead. This fix is therefore quite theoretical, as it is unknown whether there are any platforms actually affected. Related: haskell#252
Done, pls reapprove the CI workflows. |
|
Posix standard is very clear: https://pubs.opengroup.org/onlinepubs/009604599/basedefs/sys/time.h.html So this doesn't seem theoretical to me at all. It must be fixed. |
Yeah, sure, it's just a bit silly that we have no idea whether there is an actual platform where that code is being used, and if so, what that platform is… |
|
@hs-viktor any opinions? |
|
@vdukhovni what do you think about this? |
|
I'm fairly confident about this. @liskin ping me in a week (or at Zurihac) and I'll merge, unless there are objections in the meantime. |
Won't be attending ZuriHac this year unfortunately, so just a ping. 🍻 |
|
Thanks! |
3 participants
One such platform is Debian unstable armhf, which is in the process of transitioning to 64-bit time_t: https://wiki.debian.org/ReleaseGoals/64bit-time
On that platform (as well as any other glibc/musl platform), however, CTimeVal isn't used for anything at all because there are #ifdefs that prefer using
utimensatwhich takes CTimeSpec instead. This fix is therefore quite theoretical, as it is unknown whether there are any platforms actually affected.Related: #252