scope of header files
duncan.coutts at worc.ox.ac.uk
Wed Mar 5 21:18:08 EST 2008
On Wed, 2008-03-05 at 17:37 -0800, John Meacham wrote:
> On Thu, Mar 06, 2008 at 12:23:35AM +0000, Duncan Coutts wrote:
> > 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.
> Ideally there would be no need for headers at all. Everything needed is
> inherently in the foreign declaration. If anything, the headers should
> just be used as a sanity check, not actually to affect the generated
> code. It would be nice if ghc just stopped relying on them and ignored
> them altogether.
We're going to have to figure out what to do with crazy header files
that use lots of macros. For example the mage-1.1.0 package does not
compile without -fvia-C. This is because of the curses.h interface.
foreign import ccall unsafe "curses.h & ACS_UARROW"
acs_uarrow :: Ptr ChType
And what is "ACS_UARROW"? We might hope it's a pointer with a
corresponding linker symbol.
#define ACS_UARROW NCURSES_ACS('-') /* arrow pointing up */
#define NCURSES_ACS(c) (acs_map[NCURSES_CAST(unsigned char,c)])
extern NCURSES_EXPORT_VAR(chtype) acs_map;
Yay, it's an index into an array. So that obviously does not work. If we
compile without going via C we get a linker error because there is no
ACS_UARROW linker symbol. If we compile via C then through a bit of luck
it seems to compile.
There are rather too many of these C libs that define their public
interfaces as macros. I had to adjust the zlib binding the other day to
allow it to compile without -fvia-C. It now implements a couple macros
in the Haskell code. I hope zlib don't change their macro in the next
More information about the Glasgow-haskell-users