Re: [Caml-list] Interfacing with C question...

[Hendrik Tews <H.Tews@cs.ru.nl>]

"David Allsopp" <dra-news@metastack.com> writes:

   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");

Note the type! format_result_closure is not of type value, Rule 2
does not apply!

   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?

Yes it is OK. And you cannot use CAMLlocal or
register_global_root, because they only deal with values and not
pointers to values. The manual guarantees that the value pointed
to by the result of caml_named_value doesn't move. Probably
caml_named_value allocates a value outside the heap, registers it
as a global root and gives you back its address.

   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. You should think of values as pointers that point to data
that is moved around by the garbage collector. If there is any
chance that the garbage collector is called, then you must make
sure that it updates your pointer when it moves the data. Hence
you have to register the value.

If the garbage collector is not called under any circumstances
then the data will not move, the pointer doesn't need to get
updated and you don't have to register the value.

Furthermore, if your are sure Is_long(your_variable) is true
under any circumstances, you don't have to register
your_variable, because it is not a pointer. 

Of course all that is strongly discouraged.

Bye,

Hendrik