Re: [Caml-list] Win32 API

["Harry Chomsky" <harry@chomsky.net>]

> > OK, I think I'm understanding this better now.  So if a C function does
all
> > of its work using simple macros like Val_int then it's ok, but if it
does
> > anything that might cause the OCaml runtime to allocate memory, then it
has
> > to use the CAMLparam and CAMLreturn macros as described in the
> > documentation.  Is that right?
>
> Right. And CAMLlocal also.

Now, what happens in the following situation?

  some_function(alloc_something(), alloc_something_else());

I haven't declared any C variables here, so we might think there are no GC
problems.  But there are two allocations here, and it looks like the second
one might invalidate the result of the first one.  So maybe this is unsafe
after all.  Here's an improved version:

  CAMLlocal1(v);
  v = alloc_something();
  some_function(v, alloc_something_else());

Now if the second allocation invalidates the result of the first, the
runtime will update the variable v.  But what if the value of v was already
pushed onto the stack before the second allocation occurred?  (I can't
remember how the C calling convention works, so this might make more sense
if you reverse the order of the parameters.)  The runtime updates the
*variable* v, but it doesn't know about the second copy of that value that's
on the stack, so it doesn't update that, and the function still gets called
with an invalid parameter.

So the only safe solution is to go all the way:

  CAMLlocal2(v1, v2);
  v1 = alloc_something();
  v2 = alloc_something_else();
  some_function(v1, v2);

Is this correct?

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr