[MLton] Semantics of giving a .c file to mlton?

[Ryan Newton]

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");
}