[MLton] Problem with MinGW

[Matthew Fluet]

>> This is indeed the problem!
>
> I might be jumping the gun here.

Nope, you're exactly right.

> I don't know calling conventions at all, but I thought a 16 bit value gets 
> promoted to a 32 bit one?

It should; it's a long-standing latent bug in the native codegen.

> Why is the mode being pushw'd? Yes mode_t is an unsigned short, but does that 
> mean only 16 bits on the stack?

Yes, it's only taking up 16 bits, so its not following the right calling 
convention.  So, the actual reason that the open call fails may be that it 
is reading the wrong arguments off the stack (because we put the wrong 
arguments there).

> Also, open() is one of the few functions defined with varargs; this might be 
> a complicating factor.

That shouldn't be a problem.

> It's just that by adding a pushw, my patch might also be construed as 
> promoting the 16 bit value to 32 bits.

Correct.  Though gcc seems to prefer zero-extending to 32-bits over other 
ways of getting the bits in the right place on the stack.  We'll do the 
same in the native codegen.

> Admittedly, the runtime printf()s it as zero either way, so perhaps this 
> doesn't matter.