[MLton] MLton broken FFI on AMD64???

[Wesley W. Terpstra]

On Mon, Feb 14, 2011 at 7:07 PM, Matthew Fluet <matthew.fluet at gmail.com>wrote:

> BTW, it occurs to me that there isn't a good solution to this problem
> with the C codegen.  With the C codegen, MLton emits prototypes for
> _import-ed functions that are derived from the type of the imported
> function.  The prototype assumes that the function is a non-varargs.
>

That's a good point. Yuck.

[There is a second issue with Henry's particular example, where the
> MLton emitted prototype for printf disagrees with the prototype
> exported by stdio.h, so one actually gets a compile error there.]


It's not just printf. I know of several platforms where system calls in C go
through some header magic-fu. There are #define's that rename things
depending on the _XOPEN_SOURCE / etc selection. Importing *any* symbols from
system libraries is rather error-prone.

Really, the best solution is to do like the MLton runtime: write your own
functions that do the C calls and import them instead. That works with the
system header defines/etc (and also dodges the varargs problem). The
overhead is quite low; gcc optimizes those proxy methods down to a single
branch instruction if the prototypes match.


> I suppose we could also be conservative here and always emit a varargs
> prototype.
>

What do you propose? Append a ", ..." to the end of the prototype?

I don't know of any architecture where it is a problem, but might passing a
variable argument and a normal argument differ on an input-by-input basis?
Imagine "void foo(int x, ...);" where passing the first integer goes as
32-bit on the stack but the second gets sign-extended to 64-bit. I don't
think anything forbids such a hypothetically evil ABI.

The other alternative is to simply not support _import-ing of varargs
> functions.
>

Whatever we do, we should do it consistently across the codegens.

If we can't support C properly, then maybe varargs is a losing battle.
On the other hand, people rather expect 'printf' to work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton/attachments/20110217/997a6955/attachment.html