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 p79AhoAY023117 for ; Tue, 9 Aug 2011 12:43:50 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnYBAF0OQU5RZ90vkWdsb2JhbABCpzgUAQEBAQkLCwcUAyKBQAEBAQEDOj8QAgEIGAoUEDIlAgQODYdnvE+FZ18EkwWIN4g0 X-IronPort-AV: E=Sophos;i="4.67,342,1309730400"; d="scan'208";a="105038563" Received: from mtaout01-winn.ispmail.ntl.com ([81.103.221.47]) by mail4-smtp-sop.national.inria.fr with ESMTP; 09 Aug 2011 12:43:45 +0200 Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20110809104344.QJYS2720.mtaout01-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com>; Tue, 9 Aug 2011 11:43:44 +0100 Received: from romulus.metastack.com ([81.102.132.77]) by aamtaout02-winn.ispmail.ntl.com (InterMail vG.3.00.04.00 201-2196-133-20080908) with ESMTP id <20110809104344.DCRA5924.aamtaout02-winn.ispmail.ntl.com@romulus.metastack.com>; Tue, 9 Aug 2011 11:43:44 +0100 Received: from remus.metastack.local ([172.16.0.1]) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id p79Ahbcm029275 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Aug 2011 11:43:37 +0100 Received: from Remus.metastack.local ([fe80::547c:3c42:e1da:eda2]) by Remus.metastack.local ([fe80::547c:3c42:e1da:eda2%10]) with mapi id 14.01.0289.001; Tue, 9 Aug 2011 11:43:37 +0100 From: David Allsopp To: malc CC: "caml-list@inria.fr" Thread-Topic: [Caml-list] Val_int vs caml_copy_nativeint Thread-Index: AQHMVXmI0SJTJ+WZEEqClrJDEsbe6JUSQbmAgABBFYCAAATsAIAAnJaAgACIy4CAAISKsIAACuQAgAAao6A= Date: Tue, 9 Aug 2011 10:43:36 +0000 Message-ID: References: <20110808131504.d9137220d4b4401cc3450e5a@mega-nerd.com> <20110808035322.GI29083@localhost> <20110808174619.00b76d12a02f2c58c10c0108@mega-nerd.com> <20110808080356.GD29083@localhost> <4E401BC7.5040001@inria.fr> <20110809113359.c306a95842c0c86ea160025d@mega-nerd.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.0.7] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Organization: MetaStack Solutions Ltd. X-Scanned-By: MIMEDefang 2.65 on 81.102.132.77 X-Cloudmark-Analysis: v=1.1 cv=JvdXmxIgLJv2/GthKqHpGJEEHukvLcvELVXUanXFreg= c=1 sm=0 a=40hZHaDki8MA:10 a=MS3D1rwjdOQA:10 a=cTs9vV391PwA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=Y6eGRnoZLeoNsQePDW8A:9 a=qwxiPG1Y1-05WPWpymsA:7 a=CjuIK1q_8ugA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p79AhoAY023117 Subject: RE: [Caml-list] Val_int vs caml_copy_nativeint malc wrote: > 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.. Oops :$ So it does...