[MLton] wiki cvs-like tool

[Stephen Weeks]

> Are there any known problems with sockets on Cygwin?  I note that with
> mlton-20041109 on Cygwin, I get:
> 
> fluet@mfluet-pc /usr/local/src/mlton/wiki.cvs.HEAD
> $ ./wiki login http://mlton.org MatthewFluet <passwd>
> inputAll <socket>: Bad address

I can reproduce a similar error on my Cygwin (version 1.5.11) machine.
By adding a debugging message to Posix_IO_read, we can see that it is
the second read system call that fails.

1189 = Posix_IO_read (3, 0x03d677b0, 0, 4096)
...
-1 = Posix_IO_read (3, 0x03e6bd9c, 0, 4096)

On your system, you get "Bad address", which corresponds to EFAULT,
while on my system, I get "Invalid argument", which corresponds to
EINVAL. The (Linux) read man page says

  EFAULT buf is outside your accessible address space.
  EINVAL fd is attached to an object which is unsuitable for reading.

The former might indicate some kind of problem either with our GC or
mistakenly allocating a buffer of the wrong size.  The later makes
less sense to me. 

I don't trust Cygwin, so I tweaked Posix_IO_read to malloc its own
buffer and pass that to read, then memcpy the buffer to the SML
buffer.  That did not affect the behavior at all (i.e. I still get
EINVAL).  I'd be curious to see what that does on your system.  It
would offer more conclusive evidence of confusion on Cygwin's part if
we get EFAULT with a buffer that we just malloc'd.

I played around with explicitly inserting calls to inputAll at various
points (in http.sml).  What I learned is that the read succeeds if it
is before the call to Header.fromString from within Header.input and
it fails after.  Unfortunately, Header.fromString doesn't do any
system calls, so I don't see how it could make a difference.

I've run with a huge heap to verify that no GC occurs during the
entire socket creation and reading process.  That has no effect.

I tried this same program on a couple other platforms (Darwin,
FreeBSD) and it worked fine.

I'm afraid I don't have any other ideas beyond that.  

I hate to pass the bug; but, all in all, the evidence points at yet
another obscure Cygwin bug.