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=2.8 required=5.0 tests=DNS_FROM_RFC_POST,SPF_NEUTRAL 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 C28CDBC37 for ; Sat, 8 Aug 2009 15:29:24 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtQCAP0afUrRVdO3kGdsb2JhbACaCz8BAQEBCQkMBxMDoEJ1gSKPfgEDAgSEEwU X-IronPort-AV: E=Sophos;i="4.43,346,1246831200"; d="scan'208";a="34177073" Received: from mail-yw0-f183.google.com ([209.85.211.183]) by mail1-smtp-roc.national.inria.fr with ESMTP; 08 Aug 2009 15:29:24 +0200 Received: by ywh13 with SMTP id 13so2725619ywh.15 for ; Sat, 08 Aug 2009 06:29:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=L9Cd3lRqp9GufiYFhfpQ3XuoNjdeOhoqUBsQJ8SFit0=; b=WbuatQ+AKwsRDd4rdfZMcekQumsVc/dVeGN6dCTJsOZbCxuScShqzAlo5X2PW9spMO ueR6MAqiGlMp2gybTFYp2IMTvP8mX2hr6UBYG/fkMeHVPRqNHEyG7687G4PB1JhTuWHY DM+ukws3DU1rhmSrvqKpcThxV0qL+b68O1fo8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=NXhTaq2y0j+M2wMJzsXVwVU5T6qG5r3xM+zNMap3wqcm7byaNy6doUT4WMPbPEsyiR Sfa9U9Fxfn4Jju3jNb797t6OYRN43HP8djE0jyHvo3Gn3xLzfu2+L6mfalO2yfnlDuKu KRTBsqQEDaGwsvcsgq2UbXMck1rLZuLKvYXds= Received: by 10.90.67.20 with SMTP id p20mr1883993aga.63.1249738163241; Sat, 08 Aug 2009 06:29:23 -0700 (PDT) Received: from ?192.168.1.100? ([72.44.99.175]) by mx.google.com with ESMTPS id 7sm5966130aga.67.2009.08.08.06.29.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 08 Aug 2009 06:29:22 -0700 (PDT) Message-ID: <4A7D7DAF.6070904@gmail.com> Date: Sat, 08 Aug 2009 09:29:19 -0400 From: Edgar Friendly User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: ivan chollet Cc: 'Cedric Auger' , caml-list@yquem.inria.fr Subject: Re: [Caml-list] ocaml sefault in bytecode: unanswered questions References: <000301ca1809$1658efa0$430acee0$@chollet@free.fr> In-Reply-To: <000301ca1809$1658efa0$430acee0$@chollet@free.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam: no; 0.00; ocaml:01 bytecode:01 iter:01 myfun:01 myfun:01 segfault:01 ocaml:01 runtime:01 pointers:01 notation:01 pointers:01 pointer:01 indirection:01 iter:01 edgar:98 ivan chollet wrote: > You basically state that stuff like “let l = !myref in List.iter myfun l” > (where myfun modifies !myref) wouldn't produce segfault. > Why? It would mean that doing "let l = !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? when you have [myref : list ref = ref [1;2]], this is in memory as: myref -> {contents: _a} _a -> (1,_b) _b -> (2,0) 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. When you do [let l = !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. Does this make sense? E