Daniel, Your suggestion makes sense. If I were to do that -- any suggestions of how to deal with freeing that memory? Ideally, without adding a lifecycle "free" call to the user library. My thoughts would be to store the cstruct reference (malloced by C) in a ref in OCaml, then attach a finalizer to the OCaml ref that would call the corresponding C free. I suggest the ref because my understanding is that his would be guaranteed to be finalized once (as opposed to a normal value which might get copied multiple times). Thoughts on this?
Aside: I wonder if ctypes could be extended to deal with this cross platform issue fully in ctypes-land? Have others thought about this? Also: are the maintainers open to documentation contributions? I noticed that a lot of these questions on the FAQ are currently unanswered. I would be happy to throw a couple commits with documentation suggestions for the problems that I am running into. Trevor On Sat, Oct 18, 2014 at 5:34 AM, Daniel Bünzli <[email protected]> wrote: > > > Le vendredi, 17 octobre 2014 à 19:53, Trevor Smith a écrit : > > > Thank you for your reply Daniel. > > > > About the structs: perhaps I have a fundamental misconception about how > ctypes works. Libuv functions expect that the caller allocate the memory > for the struct. My understanding was that adding fields to the struct in > ctypes would affect the memory that struct takes up. > That's correct if you allocate it with ctypes, but you don't need to. Just > make a C function that allocates the struct and bind to that function. > > Daniel > > >
_______________________________________________ Ctypes mailing list [email protected] http://lists.ocaml.org/listinfo/ctypes
