Brian Hulley wrote:
I've found a thread at
http://www.haskell.org//pipermail/ffi/2002-July/000554.html where
someone else asked the same question, but apart from the problem of
'const' , and the desire to verify the actual type of the C function, I
can't find any convincing case for requiring a header. Arg promotion
would be solved if GHC just generated a prototype based on the Haskell
type, and an explicit const_cast could be added by the writer of the C
API when necessary. As for calling conventions, the FFI already
specifies them (ccall versus stdcall etc).
The reason that GHC doesn't generate the prototype is because it might
clash with an existing prototype from a header. GHC doesn't know enough
information (eg. const) to generate a correct prototype that won't clash.
Even when I do specify a header, I still get the "warning: implicit
declaration of function" message when my FFI functions are called from a
different module, even when I use -#include "Duma.h" on the command line:
C:\ghc\ghc-6.4\bin\ghc.exe -fglasgow-exts -fffi --make main.hs
-ddump-simpl -O2 -#include Duma.h -optl-mwindows -optl-lDuma
-optl-L"c:\dll"
I don't know. Try generating the .hc file and check whether it contains
the correct #include?
(Why does GHC not automatically #include the relevant header given by
the foreign import decl at each call site?)
No good reason, but we'd have to pass that information in the interface
along with the unfolding of the foreign call, which we don't right now.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
