[MLton] x86_64 branch on AIX

[Stephen Weeks]

> However, note that MLton treats the ML type 'char' as signed.  

This seems slightly odd given that chars are isomorphic to the
nonnegative integers from 0 to 255.

> So, if you have:
>    val f = _import "f": char -> char;
> then MLton will generate the following C prototype:
>    int8_t f(int8_t);
> and will compile the call to 'f' according to the C calling convention for 
> this prototype.
...
> But, we might point out on the FFI documentation page that the 
> ML type 'char' is the C type 'signed char'.  The default C type 'char' is 
> available as C_Char.t, under either an INTEGER or WORD signature 
> (depending on the signedness).

Is there any reason why we shouldn't have the "char" ML type expand to
C_Char.t?  Or does that just encourage laziness and avoid what should
really be done, which is to always use the C_*.t types when using the
FFI.  I guess there's also the same issue as with bools in getting the
information to the compiler.