Relax variadic function restrictions

[RyanGlScott]

While the Haskell FFI cannot create a foreign declaration to a variadic function that will accept an arbitrary number of arguments, it is possible to create a foreign declaration with a fixed number of arguments. For example, the C function int ioctl(int d, int request, ...) can used in Haskell by forcing to have a specific type signature:

{-# LANGUAGE ForeignFunctionInterface #-}
module Main where

import Foreign
import Foreign.C.Types

foreign import ccall "ioctl" c_ioctl :: CInt -> CInt -> Ptr () -> IO CInt

However, one cannot do this with c2hs, as it rejects all variadic functions. For example, this code:

{-# LANGUAGE ForeignFunctionInterface #-}
module Main where

import Foreign
import Foreign.C.Types

#include <sys/ioctl.h>

{#fun unsafe ioctl as c_ioctl
  {    `Int'
  ,    `Int'
  ,    `Ptr ()'
  } -> `Int' #}

will be rejected with the error:

./Main.chs:9: (column 3) [ERROR]  >>> Variadic function!
  Calling variadic functions is not supported by the FFI; the function
  is defined at ("/usr/include/sys/ioctl.h": line 41).

Would there be any issues with relaxing c2hs's restrictions on variadic functions to allow #fun bindings?

[ian-ross]

@RyanGlScott This is an interesting idea, and I can't really see any objection to it. I think I might add an extra variadic keyword (so you'd say {#fun unsafe variadic ioctl as c_ioctl ...) to mark these as special -- that would make it possible to have several instances of the same variadic function with different argument lists and different Haskell names without things being too confusing.

Now, saying that, I've no idea how easy it would be to implement this. I'll put it on the list though...

[ian-ross]

@RyanGlScott I've done something for this, although it's a little restricted. You can now do this:

module Main where

import Foreign.Ptr
import Foreign.C.Types
import Foreign.C.String

#include <stdio.h>

{#fun variadic printf(int) as printi {`String', `Int'} -> `()'#}
{#fun variadic printf(int, int) as printi2 {`String', `Int', `Int'} -> `()'#}

main :: IO ()
main = do
  printi "TST 1: %d\n" 1234
  printi2 "TST 2: %d %d\n" 13 47

You need to mark the fun hook as variadic and you need to write the C types of the extra va_args parameters you're going to pass in parentheses after the C function name.

It's not pretty, and at the moment you can only use simple C types as the additional parameters. If you want more or have problems with it as it stands, raise a ticket. I'm not completely convinced about what I've done, so consider this just a first attempt!

[RyanGlScott]

Awesome, thanks! Could you update this wiki article to include the changes to the grammar? It's not clear to me how variadic interacts with unsafe, pure, and other keywords.

Also, I assume that "simple C types" does not encompass pointers? If so, then I can't use ioctl (my motivation for submitting this bug).

[ian-ross]

@RyanGlScott That's right about "simple types" not yet covering pointers. Consider this an experimental feature for the moment. I did a slightly shoddy job for the first implementation as I'm still figuring out what the best way to deal with this is in the more general case.

The problem is that you need to know the C types for the va_args arguments you're going to pass, and that information isn't available from the C header file defining the variadic function, so it needs to go into the CHS file somehow. The problem is that this is the only case where unadorned C code appears in the CHS file, so until now things haven't been set up to allow the CHS file parser to deal with this. And that's slightly tricky, since you need to parse the C code defining the parameter types in a context where all the names defined in whatever included C header files are in scope.

I have some ideas of how to do this, hopefully in a way that should "just work" for all variations on the parameter types, but I wanted to do a slightly dumb implementation first so that I could sort out all the other parts that are needed before focusing on this C parameter type parsing problem.

I will reopen this issue and will have a go at a definitive solution later in the week. Oh, and I'll fix the documentation tomorrow.