[MLton] x86_64 branch on AIX

[Matthew Fluet]

> On PowerPC/AIX, `char' is unsigned.  GCC treats this correctly, and
> `char' is unsigned also with GCC.  I was mistaken to claim that GCC
> treats `char' as signed on AIX.
>
> The remaining problem then is that MLton seems to want that `char' is
> signed.  At least cenv.h checks for this, and signals a compiler error
> if CHAR_MIN is zero.
>
> I can certainly coerce the runtime to compile on AIX by removing the
> check for char signedness, but will something break?  The regression
> tests pass, which leads me to suspect that the check is superfluous.

The check probably is superfluous.  I added the check because it is an 
unspecified characteristic of C environments.

However, note that MLton treats the ML type 'char' as signed.  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.  That might (but usually doesn't) disagree with the C 
calling convention for the implemenation of 'f', which one might naturally 
write as:
   char f(char) { ... }

In any case, the C functions used by the runtime (basis-ffi.h) only pass 
character indirectly in vectors or arrays, so there shouldn't be much of a 
problem.  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).