Generating Function Prototypes

[Alastair Reid]

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