From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id D4329BBAF for ; Sat, 9 Jan 2010 08:58:18 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUBAGjFR0tRZ90vkWdsb2JhbACDXpd9AQEBAQkLCgcTA6sijH+BK4IuVgQ X-IronPort-AV: E=Sophos;i="4.49,247,1262559600"; d="scan'208";a="41079942" Received: from mtaout01-winn.ispmail.ntl.com ([81.103.221.47]) by mail2-smtp-roc.national.inria.fr with ESMTP; 09 Jan 2010 08:58:18 +0100 Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20100109075818.SCUY17029.mtaout01-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com> for ; Sat, 9 Jan 2010 07:58:18 +0000 Received: from romulus.metastack.com ([81.102.132.77]) by aamtaout02-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20100109075817.LWHK21638.aamtaout02-winn.ispmail.ntl.com@romulus.metastack.com> for ; Sat, 9 Jan 2010 07:58:17 +0000 Received: from Tenor ([172.16.0.8]) (authenticated bits=0) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id o097wEO7030622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 9 Jan 2010 07:58:15 GMT From: "David Allsopp" To: "'caml-list List'" References: <56670.41.177.16.252.1262195331.squirrel@41.177.16.252> <4B3BE288.4030701@citycable.ch> <3EE07409-9559-4B91-BA3E-8787D1378275@inria.fr> <4B47C201.7090201@citycable.ch> <4B47C59C.9080505@starynkevitch.net> <4B47C9BE.4060309@citycable.ch> In-Reply-To: <4B47C9BE.4060309@citycable.ch> Subject: RE: [Caml-list] problem creating .cma library Date: Sat, 9 Jan 2010 07:58:13 -0000 Message-ID: <001f01ca9101$7ee76850$7cb638f0$@romulus.metastack.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 thread-index: AQJOYe3Hx/QZ2HlF0hFApDSWarYnHgHYG/yOARsYlHgCGxJZeAILoFkoAQ7t/TQBzoBZnQ== Content-Language: en-gb Organization: MetaStack Solutions Ltd. X-Scanned-By: MIMEDefang 2.65 on 81.102.132.77 X-Cloudmark-Analysis: v=1.1 cv=1ggfb5FlKZQUfF3vzm9UBYZ2uTfLsbs/8dSljwg5+mE= c=1 sm=0 a=kW1-OaKSEkYA:10 a=80bia_e1Ai5X1doJRCYA:9 a=ehsKknnjkzby0c6yw2gA:7 a=_F3_HniIlME8mXRGYVoHiMc6jFEA:4 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 X-Spam: no; 0.00; guillaume:01 basile:01 camlparam:01 camlreturn:01 ocaml:01 damien:01 ocaml:01 camlparam:01 camlreturn:01 stubs:01 bindings:01 stubs:01 camlp:01 -like:01 18.5:98 Guillaume Yziquel: > Basile STARYNKEVITCH a =C3=A9crit : > >> > >> 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). >=20 > 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.=20 >=20 > > 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 >=20 > 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