[ocaml-ctypes] Bigarray typing problem

Daniel Bünzli daniel.buenzli at erratique.ch
Thu Dec 5 14:13:33 GMT 2013


> the Bigarray modules stores the elements as 16-bit integers, but
> exposes them (through indexing functions etc.) as ints. Ctypes does
> the same: when you ask for a pointer into the bigarray you get back a
> pointer that gives you an int when you dereference it, but behaves as
> a pointer to 16-bit integers for purposes of arithmetic etc.:

Ok it makes sense. As you said maybe it's worth providing both, but I think I'll keep making coercions for now. I expect my following weeks to be ctypes heavy, maybe things will become clearer to me and we can have a more thorough look at that with real examples in hand. 
 
That being said maybe what feels odd in that particular case is that ctypes has:

  val uint16_t : uint16 typ

and not 

  val uint16_t : int typ

i.e. it "disagrees" with bigarrays. In practice I'd prefer the latter for unsigned types smaller than 31 bits as it avoids having to use the Unsigned.UIntX.of_int functions if you try to avoid leaking ctypes types in your interface. My intuition was that you did it that way so that you can be more precise typewise (but it then asks the question why we have `val int16_t : int typ` and not some `val int16_t : int16 typ` that you have to convert aswell). 

Best,

Daniel




More information about the Ctypes mailing list