From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id E1FD37F75C for ; Mon, 8 Sep 2014 03:28:45 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of martin.jambon@ens-lyon.org) identity=pra; client-ip=66.111.4.28; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="martin.jambon@ens-lyon.org"; x-sender="martin.jambon@ens-lyon.org"; x-conformance=sidf_compatible Received-SPF: Neutral (mail3-smtp-sop.national.inria.fr: domain of martin.jambon@ens-lyon.org does not assert whether or not 66.111.4.28 is permitted sender) identity=mailfrom; client-ip=66.111.4.28; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="martin.jambon@ens-lyon.org"; x-sender="martin.jambon@ens-lyon.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@out4-smtp.messagingengine.com) identity=helo; client-ip=66.111.4.28; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="martin.jambon@ens-lyon.org"; x-sender="postmaster@out4-smtp.messagingengine.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0BALEFDVRCbwQcnGdsb2JhbABZhDeCfLUEmT8BgQ0WEAEBAQEBBhYJPoQDAQEEASMVCDgBAQQLCxgCAgUWCwICCQMCAQIBRQYNAQcBAReIHwilG3iFCI94AREGgSyIVIVNB4J5gVMBizmHDJFYGpFsTIJPAQEB X-IPAS-Result: Ak0BALEFDVRCbwQcnGdsb2JhbABZhDeCfLUEmT8BgQ0WEAEBAQEBBhYJPoQDAQEEASMVCDgBAQQLCxgCAgUWCwICCQMCAQIBRQYNAQcBAReIHwilG3iFCI94AREGgSyIVIVNB4J5gVMBizmHDJFYGpFsTIJPAQEB X-IronPort-AV: E=Sophos;i="5.04,484,1406584800"; d="scan'208";a="78069609" Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Sep 2014 03:28:44 +0200 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by gateway2.nyi.internal (Postfix) with ESMTP id 294C720706 for ; Sun, 7 Sep 2014 21:28:36 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Sun, 07 Sep 2014 21:28:36 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=+FrYdNyK1/1X4wIFUTzD4I hgewQ=; b=ARA6A6i1rRheBdJJI9cVBOVSu4pOPkFU1PCgeWF5PztkM0Y5ytGOgT p9Z8mE43zb/1lDaJiP97vJNBFgX/IYQ4dDXRrYkbtr2xRgEKhxSv7GOqUBAd00wb fog8Wa0NQ+YHn2upZoERomsgMc7v6gcfWY0tNrAqtBhr2x2wqOD6o= X-Sasl-enc: K7wlXfJ+rsjqQKzYfQUY7u6Z3YFFXKUamnIG1PZKA1UN 1410139715 Received: from [192.168.2.7] (unknown [67.180.86.2]) by mail.messagingengine.com (Postfix) with ESMTPA id 9DE026801BA; Sun, 7 Sep 2014 21:28:35 -0400 (EDT) Message-ID: <540D0642.7090205@ens-lyon.org> Date: Sun, 07 Sep 2014 18:28:34 -0700 From: Martin Jambon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Alain Frisch CC: Caml List , Jeremy Yallop References: <20140905215626.GB3416@annexia.org> <20140905221302.GE3099@annexia.org> <20140905221813.GC3416@annexia.org> <540A3B85.6010609@ens-lyon.org> <540AA0DB.1040202@ens-lyon.org> <540CA84F.8090708@frisch.fr> In-Reply-To: <540CA84F.8090708@frisch.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] segfault in simple program with 4.02 native On Sun 07 Sep 2014 11:47:43 AM PDT, Alain Frisch wrote: > On 9/6/2014 7:51 AM, Martin Jambon wrote: >> Thanks for the explanation, Jeremy. I guess atdgen will have to use >> "option refs" after all unless someone has a better idea. > > I might be missing some context, but the current code seems to playing > two different tricks with the type system: using (Obj.magic 0.) as a > dummy initial default value (to avoid references) and mutating > normally immutable fields with Obj.set_field. Is that right? Yes, exactly. > You > might be able to keep the first trick, but storing the values in local > references instead of field of the the target record (if those > references don't espace from the function, they will be represented as > local mutable variables, whose mutation might actually be more > efficient than those of the record fields), building the target > record at the end by reading from those references. Christophe Troestler also suggested this solution in a private reply. I was afraid of the cost of the refs, so it's great to know that they're optimized away. I want to thank everyone for their suggestions. It's very helpful. Martin