Use capi for syscalls that break under musl's handling of 64-bit time_t #145
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.