[MLton] Representation of strings in the FFI

[Stephen Weeks]

> Suppose the C level calls an exported function which returns
> an ML array. To get the length the C level calls the export
> intArrayLength function. At this point the C level knows the
> length - but now it doesn't know whether the array in question
> has been moved (or even removed)?

Right.

> Since exported functions can't return tuples nor pairs, the obvious
> solution of letting intArrayLength return a pair of the length and
> the array won't work.

True.  To return multiple results you could use the standard C
approach of passing in pointers to the results as parameters and
setting them on the SML side.  But at least in this case, perhaps
GC_arrayNumElements is best.

> Is the location of globals fixed?

No.


I'm not entirely sure what you're trying to do.  Here's an idea
without a lot of thought behind it -- perhaps you could build your own
registration system on the SML side to keep track of values that you
don't want to be GC'ed.  You can't prevent values from being moved,
but you can force them to remain alive until you explicitly unregister
them.  Then, you could export from SML to C routines that allow to
lookup values via the registration system so you can be sure to have
their current location.