Hi Matthew,<br><br><div class="gmail_quote">On Wed, Mar 2, 2011 at 2:26 AM, Matthew Fluet <span dir="ltr"><<a href="mailto:matthew.fluet@gmail.com">matthew.fluet@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
It would help to know a little more about exactly where your C int is<br>
coming from to know the best way to convert it to an ML int.<br>
<br>
The differences between the MLRep structures in MLton and SML/NJ are a<br>
documented design decision:<br>
<a href="http://mlton.org/MLNLFFIImplementation" target="_blank">http://mlton.org/MLNLFFIImplementation</a><br>
<a href="http://mlton.org/pipermail/mlton-user/2007-February/001025.html" target="_blank">http://mlton.org/pipermail/mlton-user/2007-February/001025.html</a><br>
I believe that the fine-grained C types better document an interface,<br>
even if the underlying SML implementation needs to coerce small sized<br>
values to larger sized values.<br>
<br></blockquote><div><br>Thanks for the links. I remember having read the page at the first link a while ago but could not remember where it was exactly I read that.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
You are meant to use MLRep.Int.Signed.toInt and<br>
MLRep.Int.Signed.fromInt to convert a C int to and from an SML Int.int<br>
(when using NLFFI generated code). Of course, those conversions could<br>
fail due to Overflow if the C int size and the SML Int.int size<br>
differ. But, note that the<br>
MLRep.{Char,Short,Int,Long,LongLong}.Signed structures match the<br>
INTEGER signature and the<br>
MLRep.{Char,Short,Int,Long,LongLong}.Unsigned structures match the<br>
WORD signature, so, often if one is doing simple arithmetic on these<br>
values, there isn't a need to explicitly convert it to an SML Int.int.<br>
<br>
If you are using NLFFI, my best suggestion is to introduce a<br>
compatibility structure. For your MLton code, you just need the<br>
following:<br>
<br>
mlton-mlrep.sml:<br>
structure ZMLRep = MLRep<br>
<br>
For your SML/NJ code, you just need the following:<br>
<br>
smlnj-mlrep.sml:<br>
structure ZMLRep = struct<br>
structure Char = struct<br>
structure Signed = MLRep.Signed<br>
structure Unsigned = MLRep.Unsigned<br>
structure SignedBitops = MLRep.SignedBitops<br>
end<br>
structure Short = struct<br>
structure Signed = MLRep.Signed<br>
structure Unsigned = MLRep.Unsigned<br>
structure SignedBitops = MLRep.SignedBitops<br>
end<br>
structure Int = struct<br>
structure Signed = MLRep.Signed<br>
structure Unsigned = MLRep.Unsigned<br>
structure SignedBitops = MLRep.SignedBitops<br>
end<br>
structure Long = struct<br>
structure Signed = MLRep.Signed<br>
structure Unsigned = MLRep.Unsigned<br>
structure SignedBitops = MLRep.SignedBitops<br>
end<br>
structure LongLong = struct<br>
structure Signed = MLRep.LongLongSigned<br>
structure Unsigned = MLRep.LongLongUnsigned<br>
(* structure SignedBitops = MLRep.LongLongSignedBitops *)<br>
end<br>
structure Float = MLRep.Real<br>
structure Double = MLRep.Real<br>
end<br>
<br>
Now, if you use ZMLRep structures to manipulate the C data, you should<br>
have code that works with both SML/NJ and MLton.<br>
<br>
Let me know if the above works. I believe that it should, and it is<br>
an innocuous enough extension of SML/NJ's existing MLRep structure<br>
that we could probably get it added to the SML/NJ version of the NLFFI<br>
Library.<br>
</blockquote></div><br>That is exactly what I've been using prior to posting the question. I just wanted to check if there was a better, more portable way.<br>It would be good if both MLton and SML/NJ used the same structure.<br>
I agree that MLton version of MLRep is better than the one in SML/NJ. I'll open a feature request to update SML/NJ's MLRep structure and look into submitting a patch.<br><br>Thanks,<br><br>Ivan<br>