<div class="gmail_quote">On Mon, Feb 14, 2011 at 7:07 PM, Matthew Fluet <span dir="ltr"><<a href="mailto:matthew.fluet@gmail.com">matthew.fluet@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div>BTW, it occurs to me that there isn't a good solution to this problem<br></div>
with the C codegen. With the C codegen, MLton emits prototypes for<br>
_import-ed functions that are derived from the type of the imported<br>
function. The prototype assumes that the function is a non-varargs.<br></blockquote><div><br>That's a good point. Yuck.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
[There is a second issue with Henry's particular example, where the<br>
MLton emitted prototype for printf disagrees with the prototype<br>
exported by stdio.h, so one actually gets a compile error there.] </blockquote><div><br>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.<br>
<br>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I suppose we could also be conservative here and always emit a varargs<br>
prototype.<br></blockquote><div><br>What do you propose? Append a ", ..." to the end of the prototype?<br><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The other alternative is to simply not support _import-ing of varargs functions.<br></blockquote><br></div>Whatever we do, we should do it consistently across the codegens.<br><br>If we can't support C properly, then maybe varargs is a losing battle.<br>
On the other hand, people rather expect 'printf' to work.<br><br>