Inconsistent Int type handling in FFI

[stepancheg]

There are issues with integer types in FFI:

• for Chez Int type is mapped to C int. On some systems (like 64 bit Linux) int is 32-bit, so it is not enough to handle for example array offset
• some native functions (like idris2_writeBufferData) declare Int parameter in Idris (thus, int in C), but accept size_t in C code. Which kinda works with current C calling conventions, but generally it is incorrect

I propose this convention: Int is mapped to intptr_t in FFI, all codegen and FFI need to be adjusted.

Possible alternatives are:

• size_t is not signed
• ssize_t is not in C standard

Note Int is smaller than intptr_t, for example, on my mac, Chez (most-positive-fixnum) is 1152921504606846975, which is (1 << 60) - 1. So Int is not enough to store a pointer, but enough to store a pointer difference.

So there will be no overflow when passing Int to FFI, but FFI function need to be careful to not produce too large integer return values.

[gallais]

Is this #1048?

[stepancheg]

Looks like it the issue you mentioned is related but different.

• This issue is about FFI specifically
• The referenced issue is about integer size/overflow handling in generated code