RE: [Caml-list] Val_int vs caml_copy_nativeint

[David Allsopp <dra-news@metastack.com>]

Erik de Castro Lopo wrote:
> Xavier Leroy wrote:
> 
> > On 08/08/2011 10:03 AM, Guillaume Yziquel wrote:
> >
> > > Then I do not see anything wrong if the code snippet you sent.
> > > However, when you change Val_int to caml_copy_nativeint, the layout
> > > of the tuple is different. [...] So if you keep the same OCaml code
> > > when reading the result value, it's no surprise that the pointer is
> > > shown in place of the integer you expected.
> >
> > This is good advice indeed: make sure your Caml type declaration
> > matches the data representation that your Caml/C stub implements...
> >
> > >    /* 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) ;
> >
> > Additionally, do make sure that "v_response" is registered with the GC
> > (declared with one of the CAMLlocal macros).
> 
> This is strange, it wasn't declared with a CAMLlocal macro and it was
> working, but if I do declare it with one the program segfaults during
> garbage collection (caml_oldify_local_roots).

If you altered this but left the program exactly the same then you violated rule 1 in 18.5.1 of the manual: CAMLparamn must come first. The result is predictable - you attempt to allocate a local variable before the local root is properly initialised...

That said, in your specific example, my understanding is that it should be OK not using CAMLlocal because you return v_response with CAMLreturn before the GC could be triggered (no allocations or callbacks between caml_alloc_tuple and CAMLreturn). Whether that's a) correct and b) sensible (i.e. whether the performance "boost" justifies the commenting needed in the code to explain how brittle it is) is another matter!


David