RE: problems with FFI including h files
2) Restrict ffi to invoking functions not macros.
In this case, GHC generates function prototypes itself based on the Haskell type and ignores the header files.
If you want to detect mismatches between function prototypes in the C header file and the GHC-generated prototypes, you could generate a C file like this:
#include
#include GHC_type_for_f *f_pointer = &f;
and you'll get told of many mismatches.
I thought we established that generating valid C prototypes from the Haskell FFI type signature wasn't possible due to the incompleteness of the Haskell type (lack of 'const' modifiers for one thing - is there anything else?).
This is roughly how the Hugs FFI header file will look once my current hacking on it is finished. The current header file contains little more than the final struct and a few typedefs.
Looks good. Simon
I thought we established that generating valid C prototypes from the Haskell FFI type signature wasn't possible due to the incompleteness of the Haskell type (lack of 'const' modifiers for one thing - is there anything else?).
Compilers use the same calling sequence whether you tell them about const or not. I believe that we can call all C functions correctly knowing only the calling convention (ccall, stdcall, etc) and the Haskell type. I certainly hope this is true since Hugs' implementation of wrappers depends on it. (Hmmm, some calling conventions do funny things when passing and returning small structs. I don't know much about this though...)
This is roughly how the Hugs FFI header file will look once my current hacking on it is finished.
Looks good.
As of course it should since I stole vast swathes from GHC's HsFFI.h :-) -- Alastair
participants (2)
-
Alastair Reid -
Simon Marlow