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=0.1 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 2BF75BC37 for ; Sat, 8 Aug 2009 19:15:01 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcCAK9PfUpRZ90vkWdsb2JhbACPSYsBAQEBAQkLCgcTA6BekhCEFwU X-IronPort-AV: E=Sophos;i="4.43,346,1246831200"; d="scan'208";a="34181220" Received: from mtaout01-winn.ispmail.ntl.com ([81.103.221.47]) by mail1-smtp-roc.national.inria.fr with ESMTP; 08 Aug 2009 19:15:00 +0200 Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090808171456.UQOU6742.mtaout01-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com>; Sat, 8 Aug 2009 18:14:56 +0100 Received: from romulus.metastack.com ([81.102.132.77]) by aamtaout02-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20090808171456.ZGYF21638.aamtaout02-winn.ispmail.ntl.com@romulus.metastack.com>; Sat, 8 Aug 2009 18:14:56 +0100 Received: from Tenor (dyn-62-56-63-171.dslaccess.co.uk [62.56.63.171]) (authenticated bits=0) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id n78HEnOm017278 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 8 Aug 2009 18:14:51 +0100 From: "David Allsopp" To: "'ivan chollet'" , "'Edgar Friendly'" Cc: References: <000301ca1809$1658efa0$430acee0$@chollet@free.fr> <4A7D7DAF.6070904@gmail.com> <000001ca1832$b950eb80$2bf2c280$@chollet@free.fr> In-Reply-To: <000001ca1832$b950eb80$2bf2c280$@chollet@free.fr> Subject: RE: [Caml-list] ocaml sefault in bytecode: unanswered questions Date: Sat, 8 Aug 2009 18:14:47 +0100 Message-ID: <000601ca184b$bcdb8f80$3692ae80$@metastack.com> 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: AcoYLD6E7DEbUqiuTKCjRYldBZJ7vwABfrEgAAXUu6A= Content-Language: en-gb Organization: MetaStack Solutions Ltd. X-Scanned-By: MIMEDefang 2.65 on 81.102.132.77 X-Cloudmark-Analysis: v=1.0 c=1 a=Zaw4sm0CBWwA:10 a=pGLkceISAAAA:8 a=ZOzjf2MOAAAA:8 a=n06BfVqjAAAA:20 a=3-nPlNpAh6iHC8Gfk5AA:9 a=4UMus6Ovt2W7SJmW_x0A:7 a=-o7A95yhUtiskyGEvi4FjPB6MBIA:4 a=MSl-tDqOz04A:10 X-Spam: no; 0.00; ocaml:01 bytecode:01 iter:01 myfun:01 semantically:01 iter:01 myfun:01 semantically:01 allocating:01 ocaml:01 segfaults:01 bytecode:01 segfault:01 runtime:01 pointers:01 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