Binding to inline functions

Duncan Coutts duncan.coutts at
Fri Aug 28 18:21:27 EDT 2009

On Tue, 2009-08-25 at 13:18 +0100, Simon Marlow wrote:
> On 23/08/2009 20:34, Duncan Coutts wrote:
> > On Sun, 2009-08-23 at 15:09 -0300, Maurí­cio CA wrote:
> >> I understand we can't use 'foreign import ccall'
> >> to wrap inline C functions. Do you think it could
> >> be possible to have an option in cabal to generate
> >> such functions in an object file when #included in
> >> a C file, in a compiler independent, portable way?
> >
> > It might be better to include this feature into hsc2hs and/or c2hs
> > (which may in turn require some help from Cabal).
> I think it would be easy to do in GHC.  We already have the machinery to 
> generate the _stub.c files and compile them.
> The main question is what the syntax should look like.  I was toying with
> foreign import capi "foo" foo :: ...

While maybe it can be done in ghc, is that the best place to put it? Do
we do so without extending the FFI spec?

The advantage of using something like hsc2hs is that we can still
compile the same code in hugs, nhc, jhc and uhc.

> I wonder whether not being able to specify the actual calling convention 
> will be a problem, however.  We are relying on the calling convention of 
> foo being implicit.  Are there cases where this might cause a problem?

If we do it via hsc2hs or c2hs then there's no need to specify any
calling convention. We just get the one declared in the header files.
This means we can handle stdcall, ccall and even crazy platform-specific
variations like __attribute__((regparam, 3)).

A generalisation of this is needed for calling "functions" defined by
macros, and C varargs functions. A similar case, that is not fully
automatic, is cases like binding functions that pass C structures by
value. The "C structs by value" problem is already on the IHG wishlist.

Both hsc2hs and c2hs support a way of outputting extra C snippets and
binding to them, though there are some limitations. Currently Cabal does
not support this feature in hsc2hs and the limitation in c2hs is that
one can only add extra C snippets to the header, not to something that
goes into a .c file to be compiled.

So, I think we should consider making these kinds of use cases easy via
c2hs and hsc2hs (and Cabal).


More information about the Libraries mailing list