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 p79A7rHv022185 for ; Tue, 9 Aug 2011 12:07:53 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMBAIUGQU5N6B+kmWdsb2JhbABCp0wBAQEBAQgLCwcUJYFAAQEEATo/BQsLDgonB0YRBhOHbQK8dIZGBIdWkDiDLog5 X-IronPort-AV: E=Sophos;i="4.67,342,1309730400"; d="scan'208";a="115358850" Received: from fe01x03-cgp.akado.ru (HELO akado.ru) ([77.232.31.164]) by mail1-smtp-roc.national.inria.fr with ESMTP; 09 Aug 2011 12:07:34 +0200 X-Drweb-SpamState: no X-Drweb-SpamScore: -100 X-DrWeb-SpamReason: (-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 292885918; Tue, 09 Aug 2011 14:07:33 +0400 Date: Tue, 9 Aug 2011 14:07:20 +0400 (MSD) From: malc X-X-Sender: malc@linmac To: David Allsopp cc: "caml-list@inria.fr" In-Reply-To: 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> 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 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.. > 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 > > > -- mailto:av1474@comtv.ru