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:av1...@comtv.ru
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
