[MLton] Semantics of giving a .c file to mlton?
Ryan Newton
rrnewton at gmail.com
Thu Oct 23 08:37:47 PDT 2008
This is perhaps an undocumented bit of functionality, but I frequently
enjoy passing .c files to mlton directly, rather than compiling them
to .o files first.
Consider the two small files attached below. They will compile as follows:
mlton -default-ann 'allowFFI true' export.sml export.c
I was (probably erroneously) under the impression that I didn't need
to do -export-header, and #include the resulting file if I was passing
in .c files directly (mlton could do that for me). Well, the above
compiles fine and runs fine on a 32 bit platform:
Running ML program...
Inside C program... calling back to ML
Got ML array: 0xb7fd2f98
Set first element
But on 64 bit platforms it the call back into ML *completes* but
returns a bogus address, then writing to that bogus address segfaults.
Running ML program...
Inside C program... calling back to ML
Got ML array: 0xffffffff910996a8
Segmentation fault
Exporting the header and including it in the .c file fixes the problem
on 64-bit machines. I can do it that way but it would be awfully nice
to officially be able to do what I happen to get away with on 32-bit
platforms.
Is this all as intended?
Thanks,
-Ryan
export.sml
=======================================================
val cfun = _import "cfun" : unit -> unit;
val _ = (_export "ARRAYALLOC_CHAR" : (int -> char array) -> unit;)
(fn len => Array.array(len,#"_"))
val _ = print "Running ML program...\n"
val _ = cfun()
export.c
=======================================================
#include <stdio.h>
//#include "export.h"
void cfun () {
printf("Inside C program... calling back to ML\n");
char* arr = ARRAYALLOC_CHAR(50);
printf("Got ML array: %p \n", arr);
arr[0] = 65;
printf("Set first element\n");
}
More information about the MLton
mailing list