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 p786McEO015446 for ; Mon, 8 Aug 2011 08:22:38 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIEAL9/P05N6B+kgWdsb2JhbABCp0sBARYmJYFAAQEEATo/BQsLGCcHRhEGE4dtArtehkYEh1aQNIMuiDc X-IronPort-AV: E=Sophos;i="4.67,336,1309730400"; d="scan'208";a="104923384" Received: from fe01x03-cgp.akado.ru (HELO akado.ru) ([77.232.31.164]) by mail4-smtp-sop.national.inria.fr with ESMTP; 08 Aug 2011 08:22:34 +0200 X-Drweb-SpamState: no X-Drweb-SpamScore: -200 X-DrWeb-SpamReason: @!Recipients (-100); (-100) X-Drweb-SpamState-Num: 0 X-Spam-Level: Received: from [10.0.66.9] ([10.0.66.9] verified) by fe01-cgp.akado.ru (CommuniGate Pro SMTP 5.2.13) with ESMTPS id 292657769; Mon, 08 Aug 2011 10:22:33 +0400 Date: Mon, 8 Aug 2011 10:22:21 +0400 (MSD) From: malc X-X-Sender: malc@linmac To: Guillaume Yziquel cc: caml-list@inria.fr In-Reply-To: <20110808060103.GX29083@localhost> Message-ID: References: <20110808131504.d9137220d4b4401cc3450e5a@mega-nerd.com> <20110808060103.GX29083@localhost> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [Caml-list] Val_int vs caml_copy_nativeint 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:av1474@comtv.ru