[MLton] A few patches we had to apply to port from version 20030716 to 20051202 and for the MinGW port

[Nicolas Bertolotti]

> >>> - bug-fix-cygwin-1_3_17.patch :
> 
> I think it would be fine to include portion of the patch that includes
> work-arounds for fpclassify and nanosleep.  This would allow a program
> compiled by MLton to be run on older Cygwin releases, without
> necessarily condoning development on that older Cygwin release.

If you build a binary for a given version of Cygwin, it will only run on
newer versions of Cygwin and will fail to run (you get a popup windows when
you try to execute it) on older versions.

So, it does not really make sense to include the workarounds only.
 
> >>> - bug-fix-solaris7.patch
> 
> I figured you had tested it.  It just seems that 0 is a safer value for
> a flag, as OR-ing it in obviously has no effect.  (I could imagine that
> some system calls raise an error if they are passed an unknown flag, but
> obviously mmap on Solaris 7 is not such a function.)

I think there is a reason why the compiler uses anonymous mapping (maybe it
is more efficient on platforms which support it) and this is why I decided
to use the real value. Then, if the binary runs on a platform which knows
the flag, it will use it. If we set it to 0, it will never be used, even on
platforms which handle it.

Another solution would be to detect the version at execution time ... but it
may be a bit complex and costly.

> >>>  - bug-fix-nethostdb-mingw.patch
> 
> There are different trade-offs.
> 
> In basis-library/net/net-host-db.sml, you could include code like the
> following:
> 
> structure Prim =
> struct
>    open Prim
>    val (getByAddress, getByName, getHostName) =
>      (if let open Primitive.MLton.OS in host = MinGW end
>          then Net.init ()
>          else ()
>       ; (getByAddress, getByName, getHostName))
> end
> 
> This would have the effect that if any of 'getByAddress', 'getByName',
> or 'getHostName' were used in the user program, then, at program
> startup, Net.init would be called just once.  (One could pull the same
> trick with the Socket.* functions.)  And you don't pay the cost of
> checking whether networking has been initialized at each use of a
> networking function.
> 
> On the other hand, this means that one will load WinSock2 DLL regardless
> of whether or not the program dynamically uses networking functions.

I'm not sure this very little performance optimization is really important
here. It's all about networking and network resources are usually much
slower than local ones.

> >>> - evol-dash-in-pathes-cygwin.patch
> It is certainly the case that the semantics of OS.Path.* functions (on
> Cygwin and MinGW) have changed since 20030716, but they have not changed
> 20051202.  Looking at the SVN log, I see that a few of those changes
> were committed on behalf of Wesley.
> 
> > Then, if we use the resulting path in a shell command, the command may
> fail
> > because the backslash will be interpreted as an escape sequence if we
> don't
> > pay attention to escape the string before. Usually, the ones who write
> code
> > or scripts for Cygwin are more familiar with Unix than Windows and do
> not
> > think they have to pay attention to such things and may be disappointed.
> 
> I appreciate the difference between Windows and Unix paths.  I'm just
> not sure whether your example above (/usr/local -> /usr\local) is an
> example of a desired conversion or is an example of a conversion you
> believe is wrong.
> 

It is a conversion I believe is wrong (I don't like getting backslashes in
paths when I use Cygwin).