Alastair: >> Well, if you disable the warning by giving gcc a consistent story, >> then the code is correct. (To give gcc a consistent story, don't >> #include any user or system-supplied headers and make sure gcc >> doesn't silently #include any of its own (as it likes to do).)
Simon: > I don't think it's possible to completely eliminate system headers > from the transitive closure of stuff we include when compiling a .hc > file. I've just taken a look at this, and it seems that while we > can eliminate a lot of the stuff we include, there are some awkward > ones: we need gmp.h for Integer operations, and that includes > <stddef.h>, and HsFFI.h needs <stdint.h> to get the int-type limits > (perhaps these could be autoconf'd). Well here's a trick that makes it ok to pull in arbitrary header files which might appeal to the assembly post-processing fans amongst us. Suppose you are compiling a module containing this ffi decl. foreign import foo :: Float -> Char 1) Have the Haskell compiler generate C code like this: #include <anything you like> #define whatever_you_want extern HsChar ffi_generated_foo(HsChar arg1); ... put GHC-generated code here ... Using the prefix "ffi_generated_" lets us be fairly confident that there is no prototype for the function i scope. 2) In the assembly postprocessor, apply the following transformation: s/ffi_generated_foo/foo/g The only thing this will mess up is use of inline functions (which won't get inlined). extern inline functions (for which gcc generates no code at all) are a bit of a problem too but the fault lies in the person who wrote the C code for writing code which won't even compile if you turn optimisation off. -- Alastair _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi