From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 36B00BBAF for ; Wed, 25 Aug 2010 21:31:38 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFABcMdUzV+668/2dsb2JhbACTJI4LviGFNwSEOohM X-IronPort-AV: E=Sophos;i="4.56,269,1280700000"; d="scan'208";a="68214641" Received: from rastageeks.org (HELO mail.rastageeks.org) ([213.251.174.188]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 25 Aug 2010 21:31:38 +0200 Received: from leonard.localnet (unknown [129.81.170.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rastageeks.org (Postfix) with ESMTPSA id 038804909F for ; Wed, 25 Aug 2010 21:47:27 +0200 (CEST) From: Romain Beauxis To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] caml_copy_string Date: Wed, 25 Aug 2010 14:33:06 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-4-amd64; KDE/4.4.5; x86_64; ; ) References: <201008241035.16215.toots@rastageeks.org> <201008252116.30488.monnier.florent@gmail.com> In-Reply-To: <201008252116.30488.monnier.florent@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201008251433.07764.toots@rastageeks.org> X-Spam: no; 0.00; memcpy:01 pointer:01 val:01 pointer:01 pointers:01 caml-list:01 strings:01 caml:02 caml:02 structures:02 string:02 string:02 linking:02 allocated:02 seems:03 Le mercredi 25 ao=FBt 2010 14:16:30, Florent Monnier a =E9crit : > > That's right. Therefore, calling caml_copy_string in noalloc mode is > > probably not a good idea.. >=20 > but no-one told to do so >=20 > there was a boxed value provided to the noalloc function, > but this function does not call caml_copy_string at all That's right, sorry for that.=20 However, the function that has noalloc still has one call to=20 caml_string_length and also a memcpy that depends on the pointer associated= to=20 the string value (String_val). It seems to me that in both case, the C function may be "tricked" by the Gc= ,=20 for instance if it reorganizes the memory, leaving the original pointer giv= en=20 to the C function pointing to a space in memory that no longer contains the= =20 allocated string. =46or such things as strings and more generally pointers linking to underly= ing=20 structures in memory, I think it is wise to use CAMLparamX and register the= =20 value so that it is not touched by the Gc during the C call. Also, you may want to try to register the value as global root. However, we= 've=20 had problems with this approach as well, though I do not recall exactly why= =2E=20 =46inally, even if you do not release the global lock in the function=20 (caml_enter_blocking_section), still, calling for instance caml_string_leng= th=20 may trigger a Gc recollection. Now, I may be wrong. In this case, I hope someone can correct me :) Romain