2011/8/8 Erik de Castro Lopo <[email protected]>:
> 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).
>
> The program is small, so I've included the working version of the
> C stub code below. In the Ocaml code I have:
>
> external iec16022ecc200 :
> int -> (* size *)
> string -> (* code *)
> (int * int * string) = "caml_iec16022ecc200"
>
> The C stub code below works. If I change "value v_response" to
> "CAMLlocal1 (v_response)" it segfaults. If I use caml_copy_nativeint()
> instead of Val_int when I'm preparing the v_response tuple I get what
> looks like a pointer instead of the small integer (ie [16, 160] range)
> I was expecting.
>
> Cheers,
> Erik
>
> #include <caml/mlvalues.h>
> #include <caml/alloc.h>
> #include <caml/memory.h>
> #include <caml/custom.h>
> #include <caml/fail.h>
> #include <caml/callback.h>
> #include <caml/bigarray.h>
>
> #include <stdio.h>
> #include <string.h>
> #include <assert.h>
>
> #include <iec16022ecc200.h>
>
>
> typedef union
> { unsigned char * u ;
> signed char * s ;
> char * c ;
> } flexi_char_ptr_t ;
>
>
> CAMLprim value
> caml_iec16022ecc200 (value v_size, value v_code)
> { unsigned char buffer [2048] ;
> flexi_char_ptr_t code, barcode ;
> int width, height, k ;
> value v_response ;
This look odd to me. I always place CAMLParam and CAMLlocal
declarations are the very beginning of the code.. Don't know if this
matters here but perhaps..
> CAMLparam2 (v_size, v_code) ;
>
> width = height = Int_val (v_size) ;
> code.c = String_val (v_code) ;
>
> barcode.u = iec16022ecc200 (&width, &height, NULL, strlen (code.c),
> code.u, NULL, NULL, NULL) ;
>
> if (barcode.u == NULL)
> { failwith ("iec16022ecc200 failed") ;
> fprintf (stderr, "%s %d: Should never get here.\n", __FILE__,
> __LINE__) ;
> exit (1) ;
> } ;
>
> /* Sanity check the buffer size. */
> assert (width * height < (int) sizeof (buffer) - 1) ;
>
> /* Need to convert the resulting 0x00 and 0x01 byte string to a text
> * string that we can pass back to Ocaml. */
> for (k = 0 ; k < width * height ; k++)
> buffer [k] = barcode.c [k] ? '1' : '0' ;
>
> /* Make sure buffer is string terminated. */
> buffer [width * height] = 0 ;
>
> /* Free the memory allocated by iec16022ecc200(). */
> free (barcode.u) ;
>
> barcode.u = buffer ;
>
> /* 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 (barcode.c)) ;
>
> CAMLreturn (v_response) ;
> } /* caml_iec16022ecc200 */
Romain
--
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
