> I can't remember whether this has come up before, but to my surprise
> I've just discovered that FFI foreign import declarations don't
> contain enough infomration to be able to determine the correct
> calling convention for a given C function.
I'd say it has all the information you need - you were using it wrong.
> Background: recently we "fixed" a bug in GHC's native code generator
> which was exposed by the following declaration:
> foreign import ccall unsafe snprintf :: CString -> CSize ->
> CString -> Float -> IO ()
> the native code generator was passing the Float as a C float on the
> stack, but snprintf() expects a double.
So that's how you should declare it then:
foreign import ccall unsafe snprintf :: CString -> CSize ->
CString -> Double -> IO ()
> Thoughts?
If we don't like having to remember the C promotion rules ourselves,
we could write a tool to do it for us. The ffi is supposed to be a
_mechanism_ to let you call things and on which you can build more
convenient layers. In this case, you can do that so there's no
problem with the ffi.
If you strongly disagree with this approach, I'd consider having GHC
emit warnings whenever you pass a float using the C calling convention
and allow the programmer to specify a "stop list" - a list of
functions not to emit warnings for (presumably because they are ones
they have a prototype for).
--
Alastair Reid Reid Consulting (UK) Ltd
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
