Re: [Caml-list] Val_int vs caml_copy_nativeint

[malc <av1474@comtv.ru>]

On Mon, 8 Aug 2011, Guillaume Yziquel wrote:

> Le Monday 08 Aug 2011 ? 09:20:17 (+0400), malc a ?crit :
> > On Mon, 8 Aug 2011, Erik de Castro Lopo wrote:
> > 
> > > Hi all,
> > > 
> > > I'm writing a C stub function to allow the calling of a C library
> > > function from ocaml. The return from the stub is a tuple and I'm
> > > doing this:
> > > 
> > >     /* Package up the result as a tuple. */
> > >     v_response = caml_alloc_tuple (3) ;
> > > 
> > >     Store_field (v_response, 0, Val_int (width)) ;
> > >     Store_field (v_response, 1, Val_int (height)) ;
> > >     Store_field (v_response, 2, caml_copy_string (code)) ;
> > > 
> > >     CAMLreturn (v_response) ;
> > > 
> > > The above works now, but didn't work when I was using
> > > caml_copy_nativeint() instead of Val_int() and I'd like to know
> > > why. I found it especially confusing because caml_copy_string()
> > > worked and was obvioulsy the right thing to do.
> > 
> > 18.5.2
> > 
> > Rule 5 
> > 
> > After a structured block (a block with tag less than No_scan_tag) 
> > is allocated with the low-level functions, all fields of this block must
> > be filled with well-formed values before the next allocation operation. If
> > the block has been allocated with  caml_alloc_small, filling is performed
> > by direct assignment to the fields of the block:
> > Field(v, n) = vn;
> > ...
> > 
> > I'd say rule 5 has been violated here.
> 
> No. caml_alloc_tuple is considered to be part of the simplified
> interface, not part of the low-level interface. Rule 5 shouldn't apply
> in this case.
> 
> One of the reasons for rule 5 is that the contents of the allocated
> block may not satisfy GC constraints. So you should not allocate with
> the blocks item pointing to inconsistent garbage as the GC may the run
> over them.
> 
> 	18.4.4
> 
> 	caml_alloc(n, t) returns a fresh block of size n with tag t.
> 	If t is less than No_scan_tag, then the fields of the block
> 	are initialized with a valid value in order to satisfy the
> 	GC constraints.
> 
> In caml_alloc function in alloc.c:
> 
> 	    if (tag < No_scan_tag){
> 	      for (i = 0; i < wosize; i++) Field (result, i) = 0;
> 	    }
> 
> and caml_alloc_tuple is roughly caml_alloc (in alloc.c) so definitely
> part of the simplified interface:
> 
> 	CAMLexport value caml_alloc_tuple(mlsize_t n)
> 	{
> 	  return caml_alloc(n, 0);
> 	}
> 
> 

I stand corrected.

-- 
mailto:av1474@comtv.ru