[MLton-user] SVN r6941 MLton/MinGW32 and FFI

[Wesley W. Terpstra]

On Tue, Nov 11, 2008 at 6:08 PM, Ville Laurikari <ville at laurikari.net> wrote:
> On Tue, Nov 11, 2008 at 04:15:26PM +0100, Wesley W. Terpstra wrote:
>> I'm also beginning to wonder if perhaps imports should default to
>> public instead of external given the number of people who've run into
>> the __imp__ link error.
>
> I think this is a good idea.  We've certainly run into the problem.
> Upgrading to a new version of MLton is problematic, because code
> updated for the new version does not work with the old version.  On
> the other hand, code working with the old version does not work with
> the new version.

I feel your pain, but changing the default to public won't completely
alleviate this. You *should* specify external for any symbols you
import from a DLL if the default is public. Of course, if you only
ever use _import (never _symbol or _address), you should be safe.

The other problem case is osx/i386. It needs special stub code to
access external functions and variables from a library. If MLton
defaults to public, then any programs on that target which _import
from a system library (functions like cos, sin, etc) will fail to link
unless "external" is specified.

Thus picking 'public' as the default would make a smooth upgrade for
MinGW, but break darwin/i386. Currently it's a smooth upgrade for
darwin, but not MinGW. For both situations and targets, though, you
really should distinguish public/external.

One could imagine a default of public for MinGW and external for
darwin, but that seems pretty arcane.

> By the way, it occured to me if nlffigen should be modified in some
> way.  The trunk version does not include an explicit scope when it
> generates code that uses _address.   Will this be a problem?

It depends, ANSI C requires that all pointers to the same function
compare for equality. Taking _address of an external function as
though it were public will violate this. However, it does seem the
uncommon program which depends on this, and I imagine gcc on MinGW
must expect programmers to get this wrong and thus does not make bad
optimization decisions because of it. Finally, _import is  100% "safe"
since you never see the address and MinGW makes automagic stub
functions to proxy the call to __imp__fname.

At any rate, it's hard to imagine how mlnlffigen could make a sane
choice. It doesn't know if you are statically or dynamically linking
to the library which corresponds to the header file it processes. At
the moment it picks nothing, aka external, which makes sense if you
are importing a dynamic library.

> I suppose importing variables may not work in some circumstances (we
> import only functions at the moment...)

I guessed as much, or the old MLton wouldn't work for you. =)

At any rate, the attached patch would change the default to public.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: default-public.patch
Type: text/x-patch
Size: 1645 bytes
Desc: not available
Url : http://mlton.org/pipermail/mlton-user/attachments/20081111/72227f36/default-public.bin