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
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
