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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 154C3BBAF for ; Wed, 27 Oct 2010 11:36:42 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMDACKPx0zZSMDdfWdsb2JhbAChWBUBAQsLCBgFH70IhUgEjVuIKw X-IronPort-AV: E=Sophos;i="4.58,245,1286143200"; d="scan'208";a="76614437" Received: from fmmailgate01.web.de ([217.72.192.221]) by mail4-smtp-sop.national.inria.fr with ESMTP; 27 Oct 2010 11:36:41 +0200 Received: from smtp03.web.de ( [172.20.0.65]) by fmmailgate01.web.de (Postfix) with ESMTP id 1992817141E9D; Wed, 27 Oct 2010 11:36:41 +0200 (CEST) Received: from [78.43.204.177] (helo=frosties.localdomain) by smtp03.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #24) id 1PB2Qy-0000O9-00; Wed, 27 Oct 2010 11:36:41 +0200 Received: from mrvn by frosties.localdomain with local (Exim 4.72) (envelope-from ) id 1PB2Qy-0000HH-Gb; Wed, 27 Oct 2010 11:36:40 +0200 From: Goswin von Brederlow To: Jacques Garrigue Cc: Jianzhou Zhao , caml-list@yquem.inria.fr Subject: Re: [Caml-list] When can we ignore CAMLparam and CAMLreturn? References: Date: Wed, 27 Oct 2010 11:36:40 +0200 In-Reply-To: (Jacques Garrigue's message of "Tue, 26 Oct 2010 09:52:59 +0900") Message-ID: <8739rsdljr.fsf@frosties.localdomain> User-Agent: Gnus/5.110009 (No Gnus v0.9) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: goswin-v-b@web.de X-Sender: goswin-v-b@web.de X-Provags-ID: V01U2FsdGVkX18w7J5IUMwcl8VP6ovkcdHKaZU0qtz7aMxqXT5q 7MvflERXd4yjcXX0r8KnOLP+DLmD6Qu45Fe27bD4aZkozze0AY C8o6JX5ZU= X-Spam: no; 0.00; camlparam:01 camlreturn:01 bindings:01 camlprim:01 wosize:01 val:01 malloc:01 sizeof:01 val:01 alloc:01 function':01 camlparam:01 camlreturn:01 ocaml:01 pointers:01 Jacques Garrigue writes: > On 2010/10/26, at 1:19, Jianzhou Zhao wrote: > >> Hi All, >> >> Here is the code from LLVM-OCaml bindings. >> >> ///////////////// >> /* llvalue -> GenericValue.t array -> ExecutionEngine.t -> GenericValue.t */ >> CAMLprim value llvm_ee_run_function(LLVMValueRef F, value Args, >> LLVMExecutionEngineRef EE) { >> unsigned NumArgs; >> LLVMGenericValueRef Result, *GVArgs; >> unsigned I; >> >> NumArgs = Wosize_val(Args); >> GVArgs = (LLVMGenericValueRef*) malloc(NumArgs * sizeof(LLVMGenericValueRef)); >> for (I = 0; I != NumArgs; ++I) >> GVArgs[I] = Genericvalue_val(Field(Args, I)); >> >> Result = LLVMRunFunction(EE, F, NumArgs, GVArgs); >> >> free(GVArgs); >> return alloc_generic_value(Result); >> } >> //////////////////////// >> >> The 'llvm_ee_run_function' does not protect the Args parameter by >> CAMLparam with CAMLreturn. Is this safe in this case, because we >> allocated a GVArgs? The Ocaml manual suggests to use CAMLparam for any >> value parameters (http://caml.inria.fr/pub/docs/manual-ocaml/manual032.html#toc140). > > The basic rule is that those macros are only needed if some allocation in the caml heap > occurs before accessing a caml value. Expressed another way, whenever allocation is > used all unprotected pointers to the caml heap should be considered as invalid. > > Since in the above code there is no allocation in the caml heap before the Genericvalue_val's, > Args need not be protected. Similarly for the result, we are just returning the result of another > function, with no risk of corruption. > > When in doubt, it is always safer to use CAMLparam/CAMLreturn, eventhough they will > generate a bit more code. As a special case: If you enter/leave_blocking_section() then some other thread might (almost certainly will) do an allocation. So any ocaml values you need in enter/leave_blocking_section() need to be copied to C values beforehand and values you need after need to be protected. MfG Goswin