From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=MSGID_FROM_MTA_HEADER autolearn=disabled version=3.1.3 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 690C5BC0B for ; Tue, 16 Jan 2007 07:42:29 +0100 (CET) Received: from alnrmhc14.comcast.net (alnrmhc14.comcast.net [204.127.225.94]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l0G6gSZB023643 for ; Tue, 16 Jan 2007 07:42:29 +0100 Message-Id: <200701160642.l0G6gSZB023643@concorde.inria.fr> Received: from monkey (c-24-3-185-40.hsd1.pa.comcast.net[24.3.185.40]) by comcast.net (alnrmhc14) with SMTP id <20070116064224b1400rodnpe>; Tue, 16 Jan 2007 06:42:25 +0000 Date: Tue, 16 Jan 2007 02:50:27 -0500 From: Bob Matcuk To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] va_arg values In-Reply-To: <875c7e070701152018s4eca17b1i72a10440e0c1edef@mail.gmail.com> References: <200701132310.l0DNArug026315@discorde.inria.fr> <875c7e070701152018s4eca17b1i72a10440e0c1edef@mail.gmail.com> X-Mailer: Sylpheed version 2.2.9 (GTK+ 2.10.7; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-j-chkmail-Score: MSGID : 45AC73D4.001 on concorde : j-chkmail score : X : 0/20 1 0.000 -> 1 X-Miltered: at concorde with ID 45AC73D4.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; hash:01 hash:01 mlvalues:01 alloc:01 malloc:01 caml's:01 exn:01 re-raise:01 printexc:01 gcc:01 compiler:01 allocates:01 stack:01 gpg:01 hardcore:98 Thank you for your long reply! This is exactly the information I was looking for. Cleared up the role of the GC for me. I'm not used to working with any kind of automatic GC; I'm somewhat of a hardcore C fanatic. It didn't occur to me that the GC might move things around, though I feel I should have known! Doh! On Mon, 15 Jan 2007 23:18:51 -0500 "Chris King" wrote: > True, false. caml_callbackN executes arbitrary code, which may or may > not trip the GC. hash_variant and caml_get_public_method are > questionable also (since they return values), but looking at the Caml > source code, it seems that they are safe (but I don't think the docs > guarantee this). Indeed. I was a bit weary of that myself. > (BTW you should use caml_hash_variant rather than hash_variant; the > comment for caml_get_public_method in caml/mlvalues.h should probably > be updated to this effect also.) Aye - I grabbed that from the documentation. I've noticed there are a couple places where the documentation is missing the "caml_" but for some reason, I didn't even think twice about that one. > You could do this with caml_stat_alloc and caml_stat_free (in > caml/memory.h). These are equivalent to malloc/free but throw Caml's > out-of-memory exception if they fail. However in this case, I would > simply declare args as an array. Otherwise, if the callback throws an > exception, args will not be freed unless you explicitly catch > exceptions via caml_callbackN_exn, free it, and then re-raise the > exception. I hadn't even thought of that! Thanks! Not used to functions that don't return other than the exec's and exit. > Note that if you have no control over the C functions higher up the > call chain (say an external library which calls your function), they > could exhibit similar problems if they are unaware of the possibility > of your function raising an exception. The best thing to do in such a > case would be to return an error condition if possible, or at the very > least, print a warning and return or exit gracefully (the functions in > caml/printexc.h help here). Excellent advice; thanks again. > K&R C doesn't, but GCC does. If you're using another compiler or some > compatibility flag, then the alloca function (usually found in > alloca.h) should do the trick. It allocates space on the stack > exactly like an array declaration does, so the guts of CAMLlocalN > should apply to it. The problem with alloca is that it is not as portable (though, I can't see what the problem is - I believe most, if not all architectures could implement it as a single instruction). Still, given your previous comment about the callback throwing an exception, perhaps it is the best way to go... Thank you again for your clarifications. -- Bob Matcuk http://www.Squeg.Net/ Explanation of My Return Address, GPG Key: http://www.Squeg.Net/returnAddr.php