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 p7GERbwH020935 for ; Tue, 16 Aug 2011 16:27:37 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoBANN9Sk4SB0QimWdsb2JhbABBmSSPEBQBAQEBAQgLCwcUJYFAAQEEAX4LC0ZXGYdwsB2If4ZIBKQj X-IronPort-AV: E=Sophos;i="4.67,380,1309730400"; d="scan'208";a="105595242" Received: from dmz-mailsec-scanner-5.mit.edu ([18.7.68.34]) by mail4-smtp-sop.national.inria.fr with ESMTP; 16 Aug 2011 16:27:36 +0200 X-AuditID: 12074422-b7ba7ae000000a14-af-4e4a7e4e43dd Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 0B.DB.02580.E4E7A4E4; Tue, 16 Aug 2011 10:27:26 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id p7GERYm3024977 for ; Tue, 16 Aug 2011 10:27:34 -0400 Received: from localhost (CONTENTS-VNDER-PRESSVRE.MIT.EDU [18.9.64.11]) (authenticated bits=0) (User authenticated as jfc@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p7GERXUo011092 for ; Tue, 16 Aug 2011 10:27:34 -0400 (EDT) Message-Id: <201108161427.p7GERXUo011092@outgoing.mit.edu> To: caml-list@inria.fr In-reply-to: <20110816103929.GB3772@NANA.localdomain> References: <20110816.105738.246515733851238101.Christophe.Troestler@umons.ac.be> <20110816103929.GB3772@NANA.localdomain> Comments: In-reply-to Mauricio Fernandez message dated "Tue, 16 Aug 2011 12:39:29 +0200." X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.1.1 Date: Tue, 16 Aug 2011 10:27:33 -0400 From: John Carr X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUixCmqretX5+VnsOKPlsWnHRtYHBg9Jr04 xBLAGMVlk5Kak1mWWqRvl8CVceL0BqaCHvaKN73bmBsYb7F2MXJySAiYSOx+N4MRwhaTuHBv PVsXIxeHkMA+Rond9/qgnJOMEqfbrrFDODOZJC7MagJr4RWwkrj64QsbiC0C1D5r/hWWLkYO DmEBS4m3fzRAwpwCphI37rxkgehtYZLoPHuOCSTBLJAtMXlxDzvEal2Jj4tmgtksAqoSW5f/ ADuPTUBW4lF7F+MERr4FjAyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdE31cjNL9FJTSjcxgsKD 3UVpB+PPg0qHGAU4GJV4eFemevoJsSaWFVfmHmKU5GBSEuU9VuvlJ8SXlJ9SmZFYnBFfVJqT WnyIUYKDWUmElzENKMebklhZlVqUD5OS5mBREufl2ungJySQnliSmp2aWpBaBJOV4eBQkuA9 CzJUsCg1PbUiLTOnBCHNxMEJMpwHaPgBkBre4oLE3OLMdIj8KUZFKXHenSAJAZBERmkeXC8s fl8xigO9Isx7BKSKBxj7cN2vgAYzAQ2+tcsDZHBJIkJKqoFxxu7Nxse2pjAy21SuNc08+TZF cpHIDNdTv9gvrj2W9n9XgdfFDewlXfdLo4rjf5oFKq/27FV4o1aq1VXU5eZ8Z/tCHXtlq99/ L0T3F21p23i6U1B/o7z+vTKjQ0eNL8jfkVa4sGgf39Ou/Vmah4qK35y8tVKzpuq7yus/22f8 vvT160xfvoMZSizFGYmGWsxFxYkAku6dEboCAAA= Subject: Re: [Caml-list] Interfacing with C: bad practice Mauricio Fernandez wrote: > This has been in my mind for a while: why don't CAMLparamX declare the local > variables as volatile? That would not help. Passing the address of a local variable to an external function warns the compiler that the variable may change when another external function is called. That is necessary and sufficient to accomodate OCaml's garbage collector. The problem here is, order of evaluation of function call arguments is unspecified. In principle the same bug is present in Field(camlvar, 1) = allocating_function(...); camlvar may be evaluated before the allocating function is called, and the allocating function may move the object it points to. I don't know whether the new C sequencing rules change this, but I wouldn't intentionally write code that depends on the ordering of this statement. --John Carr (jfc@mit.edu)