RE: problems with FFI including h files
I thought we established that generating valid C prototypes from the Haskell FFI type signature wasn't possible due to the incompleteness of the Haskell type (lack of 'const' modifiers for one thing - is there anything else?).
Compilers use the same calling sequence whether you tell them about const or not.
I believe that we can call all C functions correctly knowing only the calling convention (ccall, stdcall, etc) and the Haskell type. I certainly hope this is true since Hugs' implementation of wrappers depends on it.
Yes - but read the text I quoted before my message. I'm not talking about calling the function, I'm talking about generating C prototypes. You suggested that the Haskell compiler could generate prototypes and the C compiler could be used to check for mismatches, which would be great if it were possible, but sadly it's not. The Haskell compiler can't generate a C prototype that can be used to check for compatibility with any other C prototypes in scope, because the Haskell FFI declaration doesn't contain all the necessary information. It has just enough information to be able to call the function, nothing more. The FFI *is* restricted to invoking functions, not macros (consider GHC's native code generator, for example). However, when compiling via C, we have to rely on prototypes being in scope from external header files, because of the above problem. (look in the FFI mailing list archives, BTW - these issues were discussed at length a while back). Cheers, Simon
Yes - but read the text I quoted before my message. I'm not talking about calling the function, I'm talking about generating C prototypes. You suggested that the Haskell compiler could generate prototypes and the C compiler could be used to check for mismatches, which would be great if it were possible, but sadly it's not.
Ah, it's the checking bit you were referring to. I still think it's possible to perform some kind of basic sanity check between header files specified in the ffi spec and the Haskell type from the ffi spec though. Maybe find a way to get gcc to tell you that the arguments are passed as a 32bit int, a pointer and a single precision float and check that against the code the ffi generates. (gcc comes very close to telling you this kind of stuff if you play around in the stabs information enough - though it might be easier to modify gcc to just print it directly).
The FFI *is* restricted to invoking functions, not macros (consider GHC's native code generator, for example). However, when compiling via C, we have to rely on prototypes being in scope from external header files, because of the above problem.
What I'm saying is that we could ignore the header files completely and find some other method for checking the consistency of the ffi code with the header files. A
participants (2)
-
Alastair Reid -
Simon Marlow