From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p7862cJ7014938 for ; Mon, 8 Aug 2011 08:02:41 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssFAP16P05V2gB5ZGdsb2JhbABCpz4ZCwsGFSWBQAEBBXkQCxguFCghiAK7ag6GOASbOIg0 X-IronPort-AV: E=Sophos;i="4.67,336,1309730400"; d="scan'208";a="104921763" Received: from emailfrontal2.citycable.ch ([85.218.0.121]) by mail4-smtp-sop.national.inria.fr with SMTP; 08 Aug 2011 08:02:41 +0200 X-Alinto-smtpauth-localdomain: Yes Received: from seldon (unknown [85.218.93.111]) (Authenticated sender: guillaume.yziquel@citycable.ch) by emailfrontal2.citycable.ch (Postfix) with ESMTPA id B196720C0D4; Mon, 8 Aug 2011 08:02:36 +0200 (CEST) Received: from yziquel by seldon with local (Exim 4.72) (envelope-from ) id 1QqIth-0000Es-HE; Mon, 08 Aug 2011 08:01:15 +0200 Date: Mon, 8 Aug 2011 08:01:07 +0200 From: Guillaume Yziquel To: malc Cc: caml-list@inria.fr Message-ID: <20110808060103.GX29083@localhost> References: <20110808131504.d9137220d4b4401cc3450e5a@mega-nerd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p7862cJ7014938 Subject: Re: [Caml-list] Val_int vs caml_copy_nativeint 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); } -- Guillaume Yziquel