caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* [Caml-list] Getting some C values over to the OCaml side correctly
@ 2016-09-25  8:02 Edgar A
  2016-09-25  8:40 ` David Allsopp
  0 siblings, 1 reply; 5+ messages in thread
From: Edgar A @ 2016-09-25  8:02 UTC (permalink / raw)
  To: caml-list

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) 




^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: [Caml-list] Getting some C values over to the OCaml side correctly
  2016-09-25  8:02 [Caml-list] Getting some C values over to the OCaml side correctly Edgar A
@ 2016-09-25  8:40 ` David Allsopp
  2016-09-25  8:43   ` Edgar A
  0 siblings, 1 reply; 5+ messages in thread
From: David Allsopp @ 2016-09-25  8:40 UTC (permalink / raw)
  To: Edgar A, caml-list

Edgar A wrote:
> 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.

> 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Caml-list] Getting some C values over to the OCaml side correctly
  2016-09-25  8:40 ` David Allsopp
@ 2016-09-25  8:43   ` Edgar A
  2016-09-25 12:28     ` David Allsopp
  0 siblings, 1 reply; 5+ messages in thread
From: Edgar A @ 2016-09-25  8:43 UTC (permalink / raw)
  To: David Allsopp; +Cc: caml-list

Thank you! Yes, did read through the manual but I was concerned about the unsigned part, does that not matter? 
> On Sep 25, 2016, at 1:40 AM, David Allsopp <dra-news@metastack.com> wrote:
> 
> Edgar A wrote:
>> 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.
> 
>> 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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: [Caml-list] Getting some C values over to the OCaml side correctly
  2016-09-25  8:43   ` Edgar A
@ 2016-09-25 12:28     ` David Allsopp
  2016-10-06  9:19       ` Goswin von Brederlow
  0 siblings, 1 reply; 5+ messages in thread
From: David Allsopp @ 2016-09-25 12:28 UTC (permalink / raw)
  To: Edgar A; +Cc: caml-list

Edgar A wrote:
> On Sep 25, 2016, at 1:40 AM, David Allsopp <dra-news@metastack.com>
> wrote:
> > Edgar A wrote:
> > > 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.
> >
> > > 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Caml-list] Getting some C values over to the OCaml side correctly
  2016-09-25 12:28     ` David Allsopp
@ 2016-10-06  9:19       ` Goswin von Brederlow
  0 siblings, 0 replies; 5+ messages in thread
From: Goswin von Brederlow @ 2016-10-06  9:19 UTC (permalink / raw)
  To: caml-list

On Sun, Sep 25, 2016 at 12:28:20PM +0000, David Allsopp wrote:
> Edgar A wrote:
> > On Sep 25, 2016, at 1:40 AM, David Allsopp <dra-news@metastack.com>
> > wrote:
> > > Edgar A wrote:
> > > > 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.
> > >
> > > > 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


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2016-10-06  9:19 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-09-25  8:02 [Caml-list] Getting some C values over to the OCaml side correctly Edgar A
2016-09-25  8:40 ` David Allsopp
2016-09-25  8:43   ` Edgar A
2016-09-25 12:28     ` David Allsopp
2016-10-06  9:19       ` Goswin von Brederlow

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).