Version française
Home     About     Download     Resources     Contact us    
Browse thread
When can we ignore CAMLparam and CAMLreturn?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jacques Garrigue <garrigue@m...>
Subject: Re: [Caml-list] When can we ignore CAMLparam and CAMLreturn?
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.

Jacques Garrigue