-[ Tue, Aug 16, 2011 at 05:10:42PM +0100, Richard W.M. Jones ]----
> 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'.
For me,
wrp_ml_cons(caml_copy_string(*s), list);
with caml_copy_string changing list, fall under the rule that a value
shall not be modified twice between two sequence points. I've just read
the relevant parts of the spec and if indeed there is a sequence point
between parameters evaluation and the call itself, there are not between
the evaluation of the parameters themself (which order of evaluation is,
of course, undefined)! Please see for yourself:
[#10] The order of evaluation of the function designator,
the actual arguments, and subexpressions within the actual
arguments is unspecified, but there is a sequence point
before the actual call.
So it seams to me that the compiler if entitled to evaluate list first,
and then evaluate caml_copy_string(*s), provided it "fully" evaluates
them before the actual jump to wrp_ml_cons. This is unrelated to wether
the address of list is available to caml_copy_string or anything; the
programmer is supposed to know that the order of evaluation is undefined
and write his code accordingly.
--
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
