extended foreign decls

[Marcin 'Qrczak' Kowalczyk]

On Wed, 3 Jan 2001 malcolm-ffi at cs.york.ac.uk wrote:

> I am about to add something like {-# CCODE #include <stdio.h> #-}
> to nhc98 as a stop-gap.  Yes, this inevitably differs from whatever
> mechanism ghc currently uses.  So yes, tools like hsc2hs will have
> to know which compiler they are generating for.  Unless anyone wants
> to have a rethink now?  :-)

ghc has -#include <stdio.h> command-line option (if the header name is not
in "" or <>, "" are assumed).

Any command-line options can be put in the source thus:
{-# OPTIONS -#include <stdio.h> #-}

(These options currently have to be at the very top of the file
and AFAIK recently ghc was changed to accept more than one OPTIONS line.)

If nhc adopts that way, it must not generate prototypes itself of course.
A signature of a C function derived from Haskell is precise enough to call
the function in the right way via a native code generator, but not to
generate prototypes with exact constness etc.

hsc2hs inserts OPTIONS pragma when generating for ghc. QForeign comes with
wrappers for some libraries and a script to output hcflags, ldflags,
ldlibs. The script outputs appropriate -#include options for requested
libraries. Installation also runs ghc --add-package (on ghc >= 4.09) to
specify C includes among other things, and then e.g. -package
qforeign-curses option causes inclusion of curses.h, which makes the
former script unnecessary.

Having correct includes is especially important for ghc, because calls to
C functions may be inlined across Haskell modules. A user module doing
"import Curses" and being compiled with optiimzation and without
appropriate -#include options may cause the C compiler to call function
without prototypes, which is not legal in C99 and does not work for
argument types like char.

-- 
Marcin 'Qrczak' Kowalczyk