FFI breaking with -O?

Simon Marlow simonmar@microsoft.com
Tue, 10 Sep 2002 11:54:41 +0100

> okay, I figured out putting the -fasm after the -O and that seems to
> cause the problem to go away supporting my theory.=20
> For an example of something that breaks, the following will create an
> error when compiled via-C and not otherwise.=20
> #include <ncurses.h>
> foreign import ccall touchwin :: Window -> IO CInt
> for the ncurses included with red hat linux, i think it has=20
> something to
> do with the fact that touchwin is both #defined in terms of other
> routines AND part of the ncurses library as its own function.=20
> I imagine
> they did this to allow inlining when compiling C as well as external
> bindings and function pointers to refer to the function. many other
> routines give warnings which are #definied in similar ways.

Ah yes, the function above is #defined as follows:

  #define touchwin(win) wtouchln((win), 0, getmaxy(win), 1)

where getmaxy() is a macro which expands to an indirect structure
selection on its argument.  In GHC's via-C code, the argument is not
declared as a pointer to the right structure, so C compiler complains.

I think the right thing to do here is to have your own header file which
just #undefs all these macros, and #include it after ncurses.h.