[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2010-01-09 (07:58) |
From: | David Allsopp <dra-news@m...> |
Subject: | RE: [Caml-list] problem creating .cma library |
Guillaume Yziquel: > Basile STARYNKEVITCH a écrit : > >> > >> Why do these functions not follow the usual CAMLparam/CAMLreturn > >> macro stuff? > > > > Because they are written by the Ocaml guys (Damien knows really well > > the Ocaml garbage collector; he wrote it). And also, because these > > particular functions do not do any allocation of Ocaml values (either > > directly or indirectly). > > So, no allocation of OCaml values (or in place modification, either, I > guess) implies no need for CAMLparam/CAMLreturn stuff? Chapter 18 of the manual in Section 18.5 describes pretty much everything you need to know about writing safe stubs that work with the garbage collector. > > > My advice for people coding C code for ocaml is the following: > > > > 1. *always* use the CAMLparam/CAMLreturn/... macros. > > > > 2. if you dare not using them for some very few functions (because > > they don't allocate, ...) add a big fat comment with a warning inside. > > > > Regards > > I want to understand them so that I can abstract away in some other file > / .so, some rather usual constructs involving OCaml structures. I think > it is smarter to take some time doing this, with detailed comments all > over, than repeating the same mistakes over and over (or worse: > wondering if you made mistakes) when doing C bindings. Having written a few C stubs myself, I'd also highly recommend just following the manual and not worrying about what the macros do - if you want/need to improve allocation performance then you can use the lower-level interface for allocation (but that still involves CAMLparamn/CAMLreturn). I usually find that tricks like this (think Obj.magic) mean that when something goes wrong, there's always a niggling thought in the back of your mind that it's the trick which has broken everything when in fact it's something blindly obvious but you waste hours double-checking the tricks! In the ideal world, the C written for C stubs would be parsed by a camlp4-like pre-processor which would automatically insert the expansion of those macros where required. If you have CAMLparamn and CAMLreturn on functions which don't strictly need them then you're only creating a few more local roots than are strictly necessary which isn't likely to hurt that much... David