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/