Skip to content
This repository has been archived by the owner on Sep 20, 2023. It is now read-only.

Use CApiFFI for variadic fcntl #420

Merged
merged 4 commits into from
Nov 4, 2017

Conversation

angerman
Copy link
Contributor

@angerman angerman commented Oct 19, 2017

This came up when using the alternative -llvmng backend. Which started to complain about two functions fcntl that had different signatures. While I assume full responsibility for all llvmng bugs, it was suggested by @geekosaur, to rather use the CApiFFI extension to import variadic fcntl as multiple functions with different numbers of arguments.

This came up when using the alternative `-llvmng` backend. Which started to complain about two functions `fcntl` that had different signatures. While I assume full responsibility for all llvmng bugs, it was suggested by @geekosaur, to rather provide an explicit argument.
Use CApiFFI
@vincenthz
Copy link
Member

vincenthz commented Oct 19, 2017

I'm pretty sure that POSIX doesn't say that a variadic function is equivalent to a function of N parameters with the defaulted value to be 0.

The only truly valid solution is to consider it a truly variadic function (through CAPI, which AFAIK is the only ghc calling convention capable of handling variadic), or not to care that much, since it's not really used variadically, i.e. no one is using va_args on the other side (on most system foundation care about I think, althought haven't checked windows compat layer), the second argument determine by itself the number of actual useful argument, the 3rd register will always have a value, but I see the init to zero as the wrong solution to this problem.

There's really a need to have multiple functions I think, defaulting to 0 is not a valid solution (i.e. you push to the callee the idea that you have 3 arguments when you expect 2, if you'ld end using the va_arg stuff). Also just for the sake of avoiding to convert an int into a pointer in library code, it's useful to have different bindings for the int parameter and the ptr parameter

@angerman
Copy link
Contributor Author

@vincenthz thank you for taking a look at it.

As this PR now essentially replaces the ccall FFI

foreign import ccall unsafe "fcntl"

with the capi FFI call

foreign import capi "fcntl.h fcntl"

does it have any chance of being merged?

I'll adjust the PR subject and summary.

@angerman angerman changed the title No redefinition of fcntl with different arity. Use CApiFFI for variadic fcntl Oct 19, 2017
@vincenthz
Copy link
Member

yes, I want to read about capi in more detail first though.

@angerman
Copy link
Contributor Author

angerman commented Nov 1, 2017

Did you have any chance to look at the capi yet?

@vincenthz
Copy link
Member

so I'm not convinced that I know what I wanted to know about it , but it's seems quite harmless considering it's use all over the place in base

@vincenthz vincenthz merged commit 52bfdf9 into haskell-foundation:master Nov 4, 2017
@vincenthz
Copy link
Member

Thanks !

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants