I have encountered quite a bit of bugs in foreign bindings where "Int" was used in place of "Cint". As far as I know, no foreign function should ever take a Haskell Int, only CInts. Would it be possible to create an empty type-class of which various C-acceptable types are instances (e.g CInt, CString) but Haskell types aren't (Ints)? I am not sure this is the right solution, but I think the problem of accidentally using Int in place of CInt should be solved so that compile-time errors are received, as for x86-32 systems, no compile time or even runtime error will be issued. It will wait and crash when run on an x86-64 system. Eyal
On Tue, 2009-01-27 at 06:32 +0200, Eyal Lotem wrote:
I have encountered quite a bit of bugs in foreign bindings where "Int" was used in place of "Cint".
As far as I know, no foreign function should ever take a Haskell Int, only CInts.
Would it be possible to create an empty type-class of which various C-acceptable types are instances (e.g CInt, CString) but Haskell types aren't (Ints)?
The compiler does already know which types are valid in FFI calls. The problem perhaps is that Int is one of the allowed types, it's just that on the C side the corresponding type must be 'HsInt' and not 'int'. Unfortunately the hsc2hs tool provides no support for checking C <-> Haskell type consistency. In contrast, the c2hs tool can prevent these problems because it will generate the correct ffi import types given the C headers. Duncan
participants (2)
-
Duncan Coutts -
Eyal Lotem