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 p7GGBAu5024391 for ; Tue, 16 Aug 2011 18:11:10 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AosHADaWSk5QRFuw/2dsb2JhbABBmSePEXeBQAEBBTo/EAsYHBIUKDSHcrlLhWlfBKQI X-IronPort-AV: E=Sophos;i="4.68,234,1312149600"; d="scan'208";a="105604467" Received: from furbychan.cocan.org ([80.68.91.176]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-SHA; 16 Aug 2011 18:10:42 +0200 Received: from rich by furbychan.cocan.org with local (Exim 4.72) (envelope-from ) id 1QtMDy-0008QV-1P; Tue, 16 Aug 2011 17:10:42 +0100 Date: Tue, 16 Aug 2011 17:10:42 +0100 From: "Richard W.M. Jones" To: rixed@happyleptic.org Cc: Caml List Message-ID: <20110816161042.GA31932@annexia.org> References: <20110816152550.GA21081@annexia.org> <20110816155137.GA18365@ccellier.rd.securactive.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110816155137.GA18365@ccellier.rd.securactive.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [Caml-list] Interfacing with C: bad practice On Tue, Aug 16, 2011 at 05:51:38PM +0200, rixed@happyleptic.org wrote: > -[ Tue, Aug 16, 2011 at 04:25:50PM +0100, Richard W.M. Jones ]---- > > I think this must be a bug in your C compiler. The address of list is > > stashed in the roots struct, so the C compiler should know that list > > can be changed by the call to caml_copy_string. > > Are you certain that the C abstract machine allow for any value stored > within the frameset of a function to be changed by a function call when > the address of the variable at hand is not passed to this function? And > mandate the C compiler to handle this scenario? In other words, mandate > the C compiler to reload from the stack all values between any function > call? > > I don't think so ; or more likely I have not understood your view on > this matter? Well it would certainly help if we had a piece of runnable code to look at. The code supplied in the original email contains an infinite loop. Nevertheless, the C compiler isn't allowed to just push 'list' blindly onto the stack and assume it doesn't change across the call to 'caml_copy_string'. Calls in C are sequence points, and the compiler cannot possibly assume that 'list' won't change, because the address of 'list' has been taken *and* is directly reachable in two steps from caml__local_roots, which is a global variable. If the compiler is doing this (and we don't really have proof of that because there is no runnable code nor is a compiler + version specified), then the compiler has a bug. Rich. -- Richard Jones Red Hat