[Caml-list] Getting some C values over to the OCaml side correctly

[Edgar A]

Greetings,

I have some C values that I want to get over to the OCaml side using the FFI.

Specifically I have `uint32_t`, `intptr_t` and `int32_t` and I’m not sure how to get it over to the OCaml side correctly.

Would the uint32_t be expressed as a Int32.t? Do I really need to put an integer as block just to get it to the OCaml side, because of the 31 bit integers on the OCaml side right?

Been looking for examples but can’t find any, example code greatly appreciated, the C side and the ml side please.

Thank you,
Edgar (Algebr)

[David Allsopp]

Post by Edgar A
Greetings,
I have some C values that I want to get over to the OCaml side using the FFI.
Specifically I have `uint32_t`, `intptr_t` and `int32_t` and I’m not sure
how to get it over to the OCaml side correctly.
Would the uint32_t be expressed as a Int32.t? Do I really need to put an
integer as block just to get it to the OCaml side, because of the 31 bit
integers on the OCaml side right?

Yes, you do, unless you can guarantee that you don't need bit 31 ever. The Unix library, for example, uses a 31/63-bit int for Unix FDs (https://github.com/ocaml/ocaml/blob/trunk/otherlibs/unix/open.c) on the realistic assumption that bit 31 will never be set.

You should use a nativeint (still boxed) for an intptr_t, as that will transparently work for 32/64-bit variants.

Post by Edgar A
Been looking for examples but can’t find any, example code greatly
appreciated, the C side and the ml side please.

There's quite a lot in the manual for this (http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html) - Int32_val and Nativeint_val are the two functions for converting an OCaml value to a C type and caml_copy_int32 and caml_copy_nativeint are the equivalents for converting the C type back to an OCaml value.

Putting caml_copy_nativeint into a GitHub search reveals, for example, https://github.com/yallop/ocaml-unix-type-representations/blob/master/lib/unix_type_representation_stubs.c (you can find many more examples by searching for caml_copy_nativeint or caml_copy_int32)


David

[Edgar A]

Thank you! Yes, did read through the manual but I was concerned about the unsigned part, does that not matter?

Post by David Allsopp

Post by Edgar A
Greetings,
I have some C values that I want to get over to the OCaml side using the FFI.
Specifically I have `uint32_t`, `intptr_t` and `int32_t` and I’m not sure
how to get it over to the OCaml side correctly.
Would the uint32_t be expressed as a Int32.t? Do I really need to put an
integer as block just to get it to the OCaml side, because of the 31 bit
integers on the OCaml side right?

Yes, you do, unless you can guarantee that you don't need bit 31 ever. The Unix library, for example, uses a 31/63-bit int for Unix FDs (https://github.com/ocaml/ocaml/blob/trunk/otherlibs/unix/open.c) on the realistic assumption that bit 31 will never be set.
You should use a nativeint (still boxed) for an intptr_t, as that will transparently work for 32/64-bit variants.

Post by Edgar A
Been looking for examples but can’t find any, example code greatly
appreciated, the C side and the ml side please.

There's quite a lot in the manual for this (http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html) - Int32_val and Nativeint_val are the two functions for converting an OCaml value to a C type and caml_copy_int32 and caml_copy_nativeint are the equivalents for converting the C type back to an OCaml value.
Putting caml_copy_nativeint into a GitHub search reveals, for example, https://github.com/yallop/ocaml-unix-type-representations/blob/master/lib/unix_type_representation_stubs.c (you can find many more examples by searching for caml_copy_nativeint or caml_copy_int32)
David

[David Allsopp]

Post by Edgar A

Post by David Allsopp

Post by Edgar A
Greetings,
I have some C values that I want to get over to the OCaml side using the FFI.
Specifically I have `uint32_t`, `intptr_t` and `int32_t` and I’m not
sure how to get it over to the OCaml side correctly.
Would the uint32_t be expressed as a Int32.t? Do I really need to put
an integer as block just to get it to the OCaml side, because of the
31 bit integers on the OCaml side right?

Yes, you do, unless you can guarantee that you don't need bit 31 ever.
The Unix library, for example, uses a 31/63-bit int for Unix FDs
(https://github.com/ocaml/ocaml/blob/trunk/otherlibs/unix/open.c) on the
realistic assumption that bit 31 will never be set.
You should use a nativeint (still boxed) for an intptr_t, as that will
transparently work for 32/64-bit variants.

Post by Edgar A
Been looking for examples but can’t find any, example code greatly
appreciated, the C side and the ml side please.

There's quite a lot in the manual for this
(http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html) - Int32_val and
Nativeint_val are the two functions for converting an OCaml value to a C
type and caml_copy_int32 and caml_copy_nativeint are the equivalents for
converting the C type back to an OCaml value.
Putting caml_copy_nativeint into a GitHub search reveals, for example,
https://github.com/yallop/ocaml-unix-type-representations/blob/master/
lib/unix_type_representation_stubs.c (you can find many more examples
by searching for caml_copy_nativeint or caml_copy_int32)

Thank you! Yes, did read through the manual but I was concerned about the
unsigned part, does that not matter?

Oh ah, I missed that part. Indeed it will - obviously, for uint32_int, you can use an int64 - the only way to use an unsigned type in OCaml is to use a bigger signed type. For unsigned 64-bit ints, that's obviously more painful.

However, it can depend on what you want to do with it (for the C library you're binding). You don't lose/change any bits of a uint32_int by storing it in an int32, it just gets interpreted differently so, especially for unsigned ints being used only as bitmasks, you may be able to get away with leaving it as a signed OCaml value.


David

[Goswin von Brederlow]

Post by David Allsopp

Post by Edgar A

Post by David Allsopp

Post by Edgar A
Greetings,
I have some C values that I want to get over to the OCaml side using the FFI.
Specifically I have `uint32_t`, `intptr_t` and `int32_t` and I’m not
sure how to get it over to the OCaml side correctly.
Would the uint32_t be expressed as a Int32.t? Do I really need to put
an integer as block just to get it to the OCaml side, because of the
31 bit integers on the OCaml side right?

Yes, you do, unless you can guarantee that you don't need bit 31 ever.
The Unix library, for example, uses a 31/63-bit int for Unix FDs
(https://github.com/ocaml/ocaml/blob/trunk/otherlibs/unix/open.c) on the
realistic assumption that bit 31 will never be set.
You should use a nativeint (still boxed) for an intptr_t, as that will
transparently work for 32/64-bit variants.

Post by Edgar A
Been looking for examples but can’t find any, example code greatly
appreciated, the C side and the ml side please.

There's quite a lot in the manual for this
(http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html) - Int32_val and
Nativeint_val are the two functions for converting an OCaml value to a C
type and caml_copy_int32 and caml_copy_nativeint are the equivalents for
converting the C type back to an OCaml value.
Putting caml_copy_nativeint into a GitHub search reveals, for example,
https://github.com/yallop/ocaml-unix-type-representations/blob/master/
lib/unix_type_representation_stubs.c (you can find many more examples
by searching for caml_copy_nativeint or caml_copy_int32)

Thank you! Yes, did read through the manual but I was concerned about the
unsigned part, does that not matter?

Oh ah, I missed that part. Indeed it will - obviously, for uint32_int, you can use an int64 - the only way to use an unsigned type in OCaml is to use a bigger signed type. For unsigned 64-bit ints, that's obviously more painful.
However, it can depend on what you want to do with it (for the C library you're binding). You don't lose/change any bits of a uint32_int by storing it in an int32, it just gets interpreted differently so, especially for unsigned ints being used only as bitmasks, you may be able to get away with leaving it as a signed OCaml value.
David

I recommend looking at the ctypes module. Takes care of a lot of the
repetitive and error prone work interfacing with C.

MfG
Goswin