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=1.2 required=5.0 tests=AWL,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 693ACBC0B for ; Thu, 25 Jan 2007 07:27:52 +0100 (CET) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l0P6RpHD017676 for ; Thu, 25 Jan 2007 07:27:52 +0100 Received: by py-out-1112.google.com with SMTP id a78so196843pyh for ; Wed, 24 Jan 2007 22:27:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lHslYUyUrUKGdZw3jUktZlhXGeCGgAkUPwmiSI+ysAW166Viq4qpiaxhW8O6xfUWnBPS9OJziTcPlOLc5ZWNYXAnNdCNpIhZ3SIXb+sS3Goqs+uyZSMIckVkcgsycfzHxFkSb+Tpz8uhqqWPk4IAmwNi5wauAaQAzi9HU3vu5y0= Received: by 10.35.121.9 with SMTP id y9mr3210883pym.1169706470844; Wed, 24 Jan 2007 22:27:50 -0800 (PST) Received: by 10.35.83.2 with HTTP; Wed, 24 Jan 2007 22:27:50 -0800 (PST) Message-ID: <6b8a91420701242227n39a919d8vab80b40140a85740@mail.gmail.com> Date: Thu, 25 Jan 2007 07:27:50 +0100 From: "Remi Vanicat" To: "OCaml List" Subject: Re: [Caml-list] Interfacing with C question... In-Reply-To: <002d01c73fdc$6254d430$6a7ba8c0@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <002d01c73fdc$6254d430$6a7ba8c0@treble> X-j-chkmail-Score: MSGID : 45B84DE7.000 on discorde : j-chkmail score : X : 0/20 1 0.000 -> 1 X-Miltered: at discorde with ID 45B84DE7.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; interfacing:01 val:01 val:01 pointer:01 pointer:01 affectation:01 affectation:01 caml-list:01 macros:01 remi:01 remi:01 int:01 int:01 vanicat:01 vanicat:01 2007/1/24, David Allsopp : > Sorry if this an RADBOTFM case. Rule 2 in Chapter 18 of the manual states > that all local variables of type value must be declared using CAMLlocal > macros. However, later on when demonstrating caml_callback we get the > statements: > > value* format_result_closure = caml_named_value("format_result"); > return strdup(String_val(caml_callback(*format_result_closure, Val_int(n)))) > > (I've "simplified" the opening lines for clarity here - naturally it should > be static and once only!). > > Two questions arise: > > 1. Presumably it's OK to cache values returned by caml_named_value without > declaring them in a CAMLlocal "call" or by using register_global_root? No, any C pointer to a caml value must be known to the caml GC, because the caml GC might move the caml value. But you might no declare such a pointer if you are sur that the GC won't be triger between your affectation of the value to the C variable, and the use of the C variable.* In the given exemple, this is the case: nothing is done between the affectation and the use. By the way, when in doubt, or when you are a begginer not nowing well how the GC work, you should always use the CAMLlocal call. > 2. The result of caml_callback is passed straight to String_val. Therefore, > if I expand the line to: > > value result = caml_callback(*format_result_closure, Val_int(n))); > return strdup(String_val(result)); > > then does that work ok without using CAMLlocal1(result); Yes, for the same reason: you do nothing between the affectation of the result function, and the use of the variable.