From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 1EB507EE51 for ; Wed, 10 Apr 2013 23:04:59 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of marek@xivilization.net) identity=pra; client-ip=178.63.18.39; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="marek@xivilization.net"; x-sender="marek@xivilization.net"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of marek@xivilization.net designates 178.63.18.39 as permitted sender) identity=mailfrom; client-ip=178.63.18.39; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="marek@xivilization.net"; x-sender="marek@xivilization.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@coaxial.xivilization.net) identity=helo; client-ip=178.63.18.39; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="marek@xivilization.net"; x-sender="postmaster@coaxial.xivilization.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAF/TZVGyPxIn/2dsb2JhbABQgwbBeIEQFnSCHwEBBAE6BgEBNwEECwsYCSUPSAYTiA4Kq1KEOwEFfY4tBo8WB4NBlwKRD4MN X-IPAS-Result: AgkFAF/TZVGyPxIn/2dsb2JhbABQgwbBeIEQFnSCHwEBBAE6BgEBNwEECwsYCSUPSAYTiA4Kq1KEOwEFfY4tBo8WB4NBlwKRD4MN X-IronPort-AV: E=Sophos;i="4.87,450,1363129200"; d="scan'208";a="12719398" Received: from coaxial.xivilization.net ([178.63.18.39]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES256-SHA; 10 Apr 2013 23:04:58 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xivilization.net; s=xiv; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=oW0nAw6QA8Pr1cvyHdPqfXFDiGhxCPnXj0DmnW8v7wA=; b=HPK/0GPKO8YQYcbyKvm7beICd9lpwXENIns/B4eIvsHRPElvO/+Tq7eQj4wKUTa0aewSblHduG5QYADpH23AUw91B6myfaWQVDLPqfYuBDilp424uqfIq2XxFJYulL4u; Received: from ppp-188-174-189-75.dynamic.mnet-online.de ([188.174.189.75] helo=localhost.localdomain) by coaxial.xivilization.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UQ2CP-0008Ud-R4; Wed, 10 Apr 2013 23:04:57 +0200 Date: Wed, 10 Apr 2013 23:04:56 +0200 From: Marek Kubica To: Alain Frisch Cc: Caml List Message-ID: <20130410230456.5c2605ea@xivilization.net> In-Reply-To: <51659BC2.5030702@frisch.fr> References: <20130410181526.2597c7a4@xivilization.net> <51659BC2.5030702@frisch.fr> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] OCaml C macros, what do they do? Hello Alain, Thanks for your answer, I'm glad that I was not so far off and can see clearer now. On Wed, 10 Apr 2013 19:05:06 +0200 Alain Frisch wrote: > On 04/10/2013 06:15 PM, Marek Kubica wrote: > > - CAMLparam1(foo), notifies the GC that foo is used in this > > function and not to be collected. > > And also that the foo pointer must be updated if the corresponding > block is moved by the GC. So even if you can guarantee that foo will > not be collected (because it is accessible otherwise), you must use > CAMLparam if there is a possibility that the GC will be triggered in > the function. If I understand correctly, GC is only triggered by the caml_* allocation functions, or is there some other possibility that I am missing? > > - CAMLlocal1(foo), creates a local variable foo. This is only > > required if I want to bind some "value" type to a variable name. > > Not required if I immediately return it. > > Same as above. All local values holding OCaml values that can be > blocks (not only "ints") must reside in variables marked as > CAMLlocal/CAMLparam at the time a GC occurs. In particular, it is > generally unsafe to chain function calls without putting the > intermediate result in a local variable marked as CAMLlocal. Okay, I suspected so much but wasn't sure since when I tried chaining without CAMLlocal it worked. But an edge case might require it. I'll add CAMLlocals to my code to be on the safe side, thanks. > AFAIK, CAMLprim is only used within the OCaml distribution itself to > collect (with sed) names of builtin primitives to be exposed by > default by ocamlrun to bytecode programs. Great, so it doesn't apply to my code at all. Will remove it. regards, Marek