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