> > 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.
That's fine - but I think the FFI specification should state somewhere
that the signature for a foreign import ccall should correspond to the
type of the C call *after the C promotion rules have been applied*.
> 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.
I have no problem with this - indeed, I fully agree that we shouldn't
extend the FFI to deal with C's strange promotion rules. Nevertheless,
we need to say that we're taking this approach.
Similar problems occur with foreign exports: if you declare a foreign
export with Float arguments (eg. see addFloat in section 3.4 of the FFI
doc), does that correspond to a C function defined like this
float addFloat(a,b) float a,b; { return (a+b); }
or this
float addFloat(float a, float b) { return (a+b); }
Clearly the latter form is the desired one, but the FFI addendum should
note that, and say that in order to correctly call the function from C
you must have a visible prototype.
Cheers,
Simon
