#3238: CInt FFI exports do not use C int in _stub.h header file
-----------------------------+----------------------------------------------
Reporter: duncan | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler (FFI)
Version: 6.11 | Severity: normal
Keywords: | Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-----------------------------+----------------------------------------------
Ideally if I have a FFI export like this:
{{{
foreign export ccall foo :: CInt -> CInt
}}}
Then the `_stub.h` file should look like:
{{{
#ifdef __cplusplus
extern "C" {
#endif
extern int foo(int a1);
#ifdef __cplusplus
}
#endif
}}}
But it actually looks like:
{{{
#include "HsFFI.h"
#ifdef __cplusplus
extern "C" {
#endif
extern HsInt32 foo(HsInt32 a1);
#ifdef __cplusplus
}
#endif
}}}
So what am I complaining about? Well, I specified an FFI export mentioning
only C types but the header file uses `HsInt32`. I'd prefer an actual C
`int`. I also do not want to `#include "HsFFI.h"` because then when using
gcc to compile C code that uses this C function I have to know the full
path to ghc's include dir so that gcc can find `HsFFI.h`.
The point here is about exporting C functions and trying to integrate into
some bigger build system that will be using gcc not ghc to compile C code
and link the system together.
I realise this isn't trivial to fix, because GHC defines things like CInt
as newtypes for primitive types of known widths (like Int32). However,
perhaps there should be a known mapping, even though within the Haskell
world CInt is just a newtype. The set of FFI types is already hard-wired
into the compiler (with some rules to allow newtype unwrapping etc) so why
not extend that hard-wired knowledge to include the real C type (not just
the ABI width). This only needs to be used when generating the export
header files. An extra bit in the mapping can indicate if it's a C
primitive type or if the export header file has to `#include "HsFFI.h"`.
This ticket is related to #2926 and the solution is almost certainly the
same, but the motivation for this problem is slightly different.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3238>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
