For the MLton FFI, there are ML structures that implement INTEGER/WORD for each of the platform-dependent signed/unsigned C types. The ML int can be set by the compiler option -default-type (to Int32, Int64 or IntInf) so may not match the platform's C int type.

With Poly/ML conversions, LargeInt variants seem reasonable.

To maximize portability across compilers and platforms, I think a C interface would want to use LargeInt.int for numeric parameters on the ML side.

Phil

On 10/10/2016 18:45, David Matthews wrote:
I think Mlton uses the same precision for C int and ML int so there
won't be the issue of an overflow exception when passing values from C
to ML.  That's easier to do with a full program compiler than the
incremental compilation of Poly/ML.

David

On 10/10/2016 15:40, Kostirya wrote:
I think it should "to turn these conversions back to use FixedInt.int and
raise an exception".
It's important to preserve full compatibility with MLton, SML/NY, SML#
...

MLton:
val plus = _import "plus": (int * int) -> int;
val r = 0 + plus(1, 2)
val _ = print ( (Int.toString(r) ^ "\n" ) )

New Poly/ML:
val plus = buildCall2 ((getSymbol mylib "plus"), (cInt, cInt), cInt)
val r = 0 + plus(1, 2)
val _ = print ( (LargeInt.toString(r) ^ "\n" ) )

The difference in SML code has already appeared in:

MLton:  val _ = print ( (Int.toString(r) ^ "\n" ) )
PolyML: val _ = print ( (LargeInt.toString(r) ^ "\n" ) )


2016-10-10 16:02 GMT+03:00 David Matthews
<david.matth...@prolingua.co.uk>:

I noticed this and thought I'd committed a fix but it seems not.  The
issue is that the C "int" type may have, depending on the platform, one
more bit of precision than FixedInt.int in Poly/ML.

Now that the default int in Poly/ML is FixedInt.int that raises a
question
about how to deal with the various conversions (e.g. cInt) that could
return a value that would overflow.  Currently, c(U)Int8 and 16 have
type
"int conversion" and the rest, c(U)Int32/64 and c(U)Int have type
"LargeInt.int conversion".  While this ensures that there will never
be an
overflow when converting C values to ML it does mean there's a mismatch
between C "int" and ML "int".  I'm wondering whether to turn these
conversions back to use FixedInt.int and raise an exception when a value
will not fit and perhaps introduce new conversions (e.g. cIntLarge) to
handle the full range of values.

Does anyone have any comments?
David


On 10/10/2016 13:18, Kostirya wrote:

Hello.
I updated Poly/ML from git (commit
aa7bea141f227ea5d7feaa849763ad53fb4147d3) and found that
mlsource/extra/CInterface/Examples/NewForeignTest.sml is broken:

env LD_LIBRARY_PATH=. poly --script NewForeignTest.sml

(4, 4)
(5, 5)
(12345, ...)
NewForeignTest.sml:133: error: Type error in function application.
   Function: buildClosure1 :
      (int -> unit) * int conversion * unit conversion ->
        (int -> unit) closure
   Argument: (fn i => print (Int.toString i), cInt, cVoid) :
      (int -> unit) * LargeInt.int conversion * unit conversion
   Reason:
      Can't unify int (*In Basis*) with LargeInt.int (*In Basis*)
         (Different type constructors)
Found near buildClosure1 (fn i => print (... ...), cInt, cVoid)

Is LargeInt.int a default int type for FFI now?

Nick.



_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml

_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml


_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml


_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml

Reply via email to