From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p798iv3F019456 for ; Tue, 9 Aug 2011 10:44:57 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQCAHjyQE5RZ90xkWdsb2JhbABCpywUAQEBAQkLCwcUAxsHgUABAQEBAzpPAgEIGAoUEDIlAgQbh2e9PYVnXwSTBIg3iDI X-IronPort-AV: E=Sophos;i="4.67,342,1309730400"; d="scan'208";a="115350276" Received: from mtaout03-winn.ispmail.ntl.com ([81.103.221.49]) by mail1-smtp-roc.national.inria.fr with ESMTP; 09 Aug 2011 10:44:51 +0200 Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20110809084450.MPWX5301.mtaout03-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com> for ; Tue, 9 Aug 2011 09:44:50 +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 <20110809084450.BOWI5924.aamtaout02-winn.ispmail.ntl.com@romulus.metastack.com> for ; Tue, 9 Aug 2011 09:44:50 +0100 Received: from remus.metastack.local ([172.16.0.1]) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id p798ik5U028273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 9 Aug 2011 09:44:46 +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 09:44:45 +0100 From: David Allsopp To: "caml-list@inria.fr" Thread-Topic: [Caml-list] Val_int vs caml_copy_nativeint Thread-Index: AQHMVXmI0SJTJ+WZEEqClrJDEsbe6JUSQbmAgABBFYCAAATsAIAAnJaAgACIy4CAAISKsA== Date: Tue, 9 Aug 2011 08:44:44 +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: <20110809113359.c306a95842c0c86ea160025d@mega-nerd.com> 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=R50lirqlHffDPPkwUlkuVa99MrvKdVWo//yz83qex8g= c=1 sm=0 a=40hZHaDki8MA:10 a=MS3D1rwjdOQA:10 a=cTs9vV391PwA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=d1VfEZZeykV45PDgTwkA:9 a=0DIpMEQkoSex1iSw0pQA: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 p798iv3F019456 Subject: RE: [Caml-list] Val_int vs caml_copy_nativeint 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). 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