Closed shwestrick closed 1 year ago
Can't I just call them the way MLton expects them to be? It looks like I gave them the wrong types.
Incidentally, why does it work for me? I test with the latest release of MLton.
I changed the types. Does it work now? I'm still curious why it didn't fail for me.
Still not working unfortunately.
I'm able to trigger it with MLton also, using -codegen c
at compile time:
mlton -default-ann 'allowFFI true' -codegen c test/test.mlb test/test.c
So, it seems to work with the native codegen, but not with the C codegen. In MPL we only use the C codegen.
Perhaps @MatthewFluet can help... :)
It's a little disappointing if I have to generate C wrapper code, but hardly the end of the world. I suspect I will need to do that to support other SML compilers anyway, but MLton looked like it might not have needed it.
It looks like this issue is arising from https://github.com/diku-dk/smlfut/blob/main/src/smlfut.sml#L127-L147.
Assuming that errors are rare, then is it really necessary to use strlen
and strcpy
? Would it not be just as easy to use MLton.Pointer.getWord8
and some loops?
In any case, using strcpy
to mutate an SML string is undefined behavior (for MLton). MLton assumes that SML strings are immutable; in particular, seeing val s = CharVector.tabulate (Word64.toInt n, fn _ => #" ")
, it can assume that s
only contains #" "
elements and optimize accordingly. (Of course, as with many undefined behaviors, it will most likely work the way you want.)
You might as well use val s = CharVector.tabulate (Word64.toInt n, fn i => Char.chr (Word8.toInt (MLton.Pointer.getWord8 (p, i))))
.
I like Matthew's suggestion!
The generated code uses
_import "strlen" public : ...
and_import "strcpy" public : ...
to manipulate strings returned byfuthark_context_get_error
.However, the MLton/MPL FFI isn't happy with these imports:
An immediate workaround would be to also generate a small
.c
file that wraps these functions with new names, but that's a bit awkward. Not sure what the best solution is yet.