Re: [Caml-list] Interfacing with C: bad practice

["Will M. Farr" <wmfarr@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1767 bytes --]

Yes.  The C compiler can see that the address of list has been passed to external functions in CAMLlocal, so has to assume the worst: that the address is stored in some global variable, and caml_copy_string or the functions it calls can access it and thereby change the value of list.  If the compiler is a spectacularly optimizing one (i.e. performs a ton of inter-module procedure inlining and/or very careful escape analysis), it *may* be able to prove that this never happens, and therefore would be allowed to optimize the call in the manner proposed.  In this case, of course, "the worst" actually happens, so such a proof must fail; if the proof does not fail, the compiler has a bug.

Will

On Aug 16, 2011, at 11:51 AM, 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?
> 
> 
> -- 
> 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
> 


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 243 bytes --]