Re: [GHC] #3238: CInt FFI exports do not use C int in _stub.h header file

2009-05-24 Thread GHC
#3238: CInt FFI exports do not use C int in _stub.h header file
-+--
Reporter:  duncan|Owner:  
Type:  bug   |   Status:  new 
Priority:  normal|Milestone:  6.12 branch 
   Component:  Compiler (FFI)|  Version:  6.11
Severity:  normal|   Resolution:  
Keywords:|   Difficulty:  Unknown 
Testcase:|   Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |  
-+--
Changes (by igloo):

  * difficulty:  = Unknown
  * milestone:  = 6.12 branch

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3238#comment:1
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


[GHC] #3238: CInt FFI exports do not use C int in _stub.h header file

2009-05-16 Thread GHC
#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