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 at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml