RE: [Caml-list] Val_int vs caml_copy_nativeint

[malc <av1474@comtv.ru>]

On Tue, 9 Aug 2011, David Allsopp wrote:

> 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). 

I'm puzzled by this, caml_copy_string does allocation..

> 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
> 
> 
> 

-- 
mailto:av1474@comtv.ru