On Tue, Aug 16, 2011 at 05:51:38PM +0200, [email protected] 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 -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
