scope of header files
duncan.coutts at worc.ox.ac.uk
Wed Mar 5 19:23:35 EST 2008
On Wed, 2008-03-05 at 23:46 +0000, Ross Paterson wrote:
> On Wed, Mar 05, 2008 at 11:16:14PM +0000, Duncan Coutts wrote:
> > I was under the impression that with ghc, ffi import declarations like
> > this do not escape the module:
> > foreign import ccall unsafe "foo.h foo" foo :: IO ()
> GHC can inline the stub across module (and thus package) boundaries,
> so the #include can escape.
I've been informed before that:
foreign import ccall unsafe "foo" foo :: IO ()
can escape and needs -#include on the command line and for all client
code. However for ghc:
foreign import ccall unsafe "foo.h foo" foo :: IO ()
does not escape because ghc does not track which .h file should be
#included later. It's not that it couldn't escape according to the FFI
spec but that ghc currently does not do cross-module inlining for such
declarations. That's what I've been told and it's the behaviour I've
observed, except for the case I noted.
Quite a few packages rely on ghc's behaviour on this, or just rely on
the fact that in practise things do not get inlined that aggressively.
If we started looking carefully I think we'd find most hackage packages
that use FFI get this wrong.
> > It's hard to tell what header files need to be used globally and
> > inherited by client packages and which can safely be used privately.
> No, it's easy: they're all potentially inherited.
Which is really annoying :-) I'd like greater control over it, in
particular a way to limit headers to package scope so that dependent
code does not need the headers.
More information about the Glasgow-haskell-users