[MLton] Two questions about FFI types

[Tom 7]

I'm currently making a small interface to the mysql database server in 
mlton. Two issues come up:

1. Some of the mysql functions take a number of C strings (character 
pointers), that behave differently if they are null. Unfortunately there 
doesn't appear to be a way to give a type to these C functions for 
_import; string doesn't work because I can't pass null, and 
MLton.Pointer.t doesn't work because I can't pass string. The only two 
solutions I have to this are (a) to import the function at multiple types, 
and then call the one that matches my dynamic set of nulls--there are then 
2^n imports in general! or (b) write a C stub that takes, for each 
argument, a char* and a bool to indicate if it is supposed to "be null". 
Neither of these is very nice to me. I'd be the first to argue that null 
is an abomination, but it is very common in C libraries that mlton 
programs would want to interface with, so are there any prospects of being 
able to do this a cleaner way? (Or is there already a cleaner way?)

2. Since this interfaces with a database (and in fact my task will be very 
data-intensive), I want to avoid copying as much as possible. I need to 
make one copy to read data from rows returned from the server and generate 
the mlton representation, and I'd like to limit it to that--but I want to 
be manipulating strings in my program, not character arrays. According to 
the FFI documentation, it appears that one way to do this would be to pass 
a CharVector (=string) to the FFI, and have the C code modify it in place:

let
   (* s would be allocated based on its target length *)
   val s = "_______"
   val f = _import "f" : string -> unit ;
in
   f s;
   ... s ...
end

But is this safe? Will the mlton optimizer, knowing that strings are 
immutable, make them share space (hash consing?) or optimize subscripts on 
constant strings? I can't tell from the FFI docs.

If it's not safe, is there some way to go from C->array->vector that 
doesn't do two copies? I'm already doing FFI, so I don't mind if it's not 
type-safe (but it obviously needs to be robust).

  - Tom


[ NEW! : http://tom7.org/       ]
[ OLD! : http://fonts.tom7.com/ ]