I've changed the Foreign structure and signature so the cInt/cInt32 etc
conversions that previously converted to LargeInt.int now convert to
int. That does mean that there are going to be C values that will raise
Overflow when passed to ML. I've added cIntLarge etc that convert to
LargeInt.in
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, Large
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
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 th
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 funct
