[MLton] Problem with MinGW

[Matthew Fluet]

> First off, the patch fixes the problem.

Good.

> 'make clean' doesn't remove mllex and mlyacc. Is there a reason for this? It 
> just bit me.

It isn't intentional.  The executables are removed by 'make clean' because 
they are listed in the .ignore file.  I presume on MinGW, the executables 
have .exe extensions, so we can add those to the .ignore.

> Also, mlyacc uses TextIO.openOut and this is creating read-only files. 
> Intentional?

I don't quite follow what the concern is.

> On Jun 9, 2006, at 12:29 AM, Matthew Fluet wrote:
>> 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).
>
> At first I was going to say: This is not right, as the runtime makes the 
> system call, not the assembler. Therefore, the value is being promoted to a 
> 32 bit integer as required by the wrapper. The only artifact carried over 
> into the windows system call is the misaligned stack.

No, the runtime function (Posix_FileSys_open3) is compiled by gcc assuming 
that it will be called according to the C calling convention.  So, it will 
assume that the mode has been passed as a 32-bit value.  If it doesn't 
just tail-call, it will blindly copy 3 32-bit arguments from the stack. 
But, since the assembly pushed 2 32-bit arguments and 1 16-bit argument, 
Posix_FileSys_open3 will copy 16-bits of the _previous_ frame over into 
the call to open.

> Then I realized that gcc might be smart enough to turn the runtime function 
> call into a tail-call, thus leaving the (bad) mode on the stack unchanged for 
> the system method.

That's possible.  Still messes things up.