From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.5 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR, MSGID_MULTIPLE_AT autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 9A8E0BC37 for ; Sun, 9 Aug 2009 03:46:00 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYCAMDGfUrLOwGUkWdsb2JhbACPSYsBAQEBAQkLCgcTBKFgkVuEFwWCJw X-IronPort-AV: E=Sophos;i="4.43,347,1246831200"; d="scan'208";a="32229478" Received: from outbound.icp-qv1-irony-out3.iinet.net.au ([203.59.1.148]) by mail3-smtp-sop.national.inria.fr with ESMTP; 09 Aug 2009 03:45:58 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtQEADfHfUp8qHif/2dsb2JhbACPSa0hkVuEFwWCJw X-IronPort-AV: E=Sophos;i="4.43,347,1246809600"; d="scan'208";a="488972471" Received: from unknown (HELO ivanz27oq2f1va) ([124.168.120.159]) by outbound.icp-qv1-irony-out3.iinet.net.au with ESMTP; 09 Aug 2009 09:45:54 +0800 From: "ivan chollet" To: "'David Allsopp'" Cc: References: <000301ca1809$1658efa0$430acee0$@chollet@free.fr> <4A7D7DAF.6070904@gmail.com> <000001ca1832$b950eb80$2bf2c280$@chollet@free.fr> <000601ca184b$bcdb8f80$3692ae80$@metastack.com> In-Reply-To: <000601ca184b$bcdb8f80$3692ae80$@metastack.com> Subject: RE: [Caml-list] ocaml sefault in bytecode: unanswered questions Date: Sun, 9 Aug 2009 03:45:44 +0200 Message-ID: <000601ca1893$1d1931d0$574b9570$@chollet@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoYLD6E7DEbUqiuTKCjRYldBZJ7vwABfrEgAAXUu6AAEkinIA== Content-Language: fr X-Spam: no; 0.00; ocaml:01 bytecode:01 iter:01 myfun:01 iter:01 myfun:01 ocaml:01 bytecode:01 semantically:01 semantically:01 allocating:01 segfaults:01 segfault:01 runtime:01 pointers:01 Hello David, I was just saying that because Edgar seemed to imply that "let l =3D = !myref in List.iter myfun l" behaved differently than "List.iter myfun = !myref" but you think they behave the same.=20 It's fine for me. Thanks! -----Original Message----- From: David Allsopp [mailto:dra-news@metastack.com]=20 Sent: samedi 8 ao=C3=BBt 2009 19:15 To: 'ivan chollet'; 'Edgar Friendly' Cc: caml-list@yquem.inria.fr Subject: RE: [Caml-list] ocaml sefault in bytecode: unanswered questions Apologies if I'm missing something obvious (I had a good lunch)... Ivan Chollet wrote: > Yes, makes sense. But it would mean that "List.iter myfun !myref" is > not semantically equivalent to "List.iter myfun (let l=3D!myref in = l)", How does this follow from Edgar's explanation? (below) > therefore the expressions "let l=3D!myref in l" and "!myref" are not > semantically equivalent. These expressions are semantically equivalent: the former merely = (locally) aliases the name [l] to the result [!myref] before returning = it. Aliasing a value is not the same as allocating memory. For example: let a =3D "1" in let b =3D a;; Results in one allocation (a value containing the string "1") and one = aliasing of the name [b] to represent the same value. So, considering your example, observe: let myref =3D ref [1; 2] in let l =3D !myref in l =3D=3D !myref;; which is [true]. [l] and [!myref] are physically the same value - i.e. = the [let l] expression did not result in an allocation. Ivan Chollet previously wrote: > Why? It would mean that doing "let l =3D !myref" creates a brand new = OCaml entity, l, ie a brand new=20 > allocation on the heap, and then, messing around with !myref inside = myfun would be of course 100% safe.=20 Two problems: firstly, let l =3D !myref does not result in an allocation = (because [l] is simply an alias for the contents of myref at the time of = the [let]). Secondly, you cannot mess around with !myref - the content = of a reference is immutable, it is only the reference itself which can = be changed (notwithstanding 'a ref ref and so on). Once you said = [List.iter myfun !myref], you pass the contents of [myref] to = [List.iter] and [myfun] can do whatever it likes with the *reference* = [myref] without affecting those contents at that point and so the = processing of [List.iter]. Do you have an actual case which segfaults? HTH, David=20 >=20 > That would be very strange! >=20 >=20 > -----Original Message----- > From: Edgar Friendly [mailto:thelema314@gmail.com] > Sent: samedi 8 ao=C3=BBt 2009 15:29 > To: ivan chollet > Cc: 'Cedric Auger'; caml-list@yquem.inria.fr > Subject: Re: [Caml-list] ocaml sefault in bytecode: unanswered > questions >=20 > ivan chollet wrote: > > You basically state that stuff like =E2=80=9Clet l =3D !myref in = List.iter > myfun l=E2=80=9D > > (where myfun modifies !myref) wouldn't produce segfault. > > Why? It would mean that doing "let l =3D !myref" creates a brand new > OCaml > > entity, l, ie a brand new allocation on the heap, and then, messing > around > > with !myref inside myfun would be of course 100% safe. Is that what > OCaml > > runtime does? >=20 > when you have [myref : list ref =3D ref [1;2]], this is in memory as: >=20 > myref -> {contents: _a} > _a -> (1,_b) > _b -> (2,0) >=20 > I've given names to the intermediate pointers -- the notation above > shows names as pointers to data structures. [myref] is a pointer to a > record, whose contents point to the head of the list [1;2]. So = there's > already two levels of indirection. >=20 > When you do [let l =3D !myref], [l] gets assigned [_a], so it points = to > the head of the list. List.iter traverses the list not even knowing > that [myref] exists, so if the function [myfun] modifies [myref], it > won't affect List.iter. >=20 > Does this make sense? >=20 > E >=20 > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs