<div dir="ltr">On Mon, Sep 22, 2008 at 1:27 PM, Wesley W. Terpstra <span dir="ltr">&lt;<a href="mailto:wesley@terpstra.ca">wesley@terpstra.ca</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div dir="ltr">Attached is a minimal test case. The expected output (as produced by the C and native codegens):<br><div style="margin-left: 40px;">&gt; m5_open called<br>&gt; libm3smlFnPublic called<br></div>The output when compiled with the bytecode codegen:<br>

<div style="margin-left: 40px;">&gt; libm3smlFnPublic called<br>&gt; m5_open called<br>libm3smlFnPublic pointers don&#39;t match!<br>&gt; libm3smlFnPublic called<br></div><br>Compile line:<br><div style="margin-left: 40px;">

mlton -default-ann &#39;allowFFI true&#39; -codegen bytecode foo.sml foo.c<br></div><br>Problem appears in both svn/HEAD and 20070826.<br></div></blockquote><div><br>Found and squashed. The problem was that the bytecodegen only looked at a symbol name for use in its MLton_callC function. This meant it used the same code to access the address of a symbol and also to call the symbol (if it is a function). <br>
<br>To fix this, I added an additional field to the key used in the hash table (symbol : bool) backing MLton_callC.<br><br></div></div></div>