Re: Bug in mlnlffigen on Win64 (bad size for 'long')

Matthew Fluet <[email protected]> Mon, 25 Jun 2012 11:02:33 -0400
Newsgroups gmane.comp.lang.ml.mlton.devel
Message-ID <CAMrhFL7duXWy8T7ycG2A-vnZwXWr=WJvKm8izbVXw3H8DRh0Bg@mail.gmail.com>
On Thu, Jun 21, 2012 at 9:25 AM, Nicolas Bertolotti
<[email protected]> wrote:
> I just noticed that ‘mlnlffigen’ generated wrong data on Win64 for the C
> type ‘long’.
>
> On Win64, a ‘long’ is 32 bits but ‘mlnlffigen’ always assumes 64 bits for
> the ‘amd64’ processor. It uses a file sizes-amd64.sml which is not
> automatically generated and whose behaviour does not depend on the operating
> system.

Indeed, none of the sizes-*.sml files are (explicitly) OS dependent.
But, obviously, they depend upon the platform upon which the files
were generated.

> I fixed the issue in my personal build by adding a file
> sizes-amd64-mingw.sml and referencing it rather than sizes-amd64.sml in
> control.sml when the target is Win64.

That seems to be a reasonable fix.  If you send along a patch, then
I'll be happy to commit it.

> Anyway, it seems that this file was automatically generated in the original
> (SML/NJ) version so I guess a more robust fix could be implemented.

Overall, I think the whole platform double ($(ARCH)-$(OS)) or even
GNU-style triple are fairly fragile.

For mlnlffigen, there seems to be no particular reason that the
sizes-*.sml files are, in fact, .sml files.  They could just as easily
be simple text files that are read (on demand) by mlnlffigen.  That
would simplify adding new platform specific size files.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/