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.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 072F8BC6C for ; Tue, 29 Jan 2008 08:51:21 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAMBpnkcRlBBTp2dsb2JhbACQHgEBAQEBAQUEBAsCHpwA X-IronPort-AV: E=Sophos;i="4.25,268,1199660400"; d="scan'208";a="6682997" Received: from smtpoutm.mac.com ([17.148.16.83]) by mail2-smtp-roc.national.inria.fr with ESMTP; 29 Jan 2008 08:51:20 +0100 Received: from mac.com (asmtp001-s [10.150.69.64]) by smtpoutm.mac.com (Xserve/smtpout020/MantshX 4.0) with ESMTP id m0T7pJco011898 for ; Mon, 28 Jan 2008 23:51:19 -0800 (PST) Received: from [192.168.8.152] (c-24-218-151-219.hsd1.ma.comcast.net [24.218.151.219]) (authenticated bits=0) by mac.com (Xserve/asmtp001/MantshX 4.0) with ESMTP id m0T7pEIu005888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 28 Jan 2008 23:51:15 -0800 (PST) Message-Id: <843642F8-3C39-480B-A8FC-295A89CC460B@mac.com> From: Gordon Henriksen To: caml-list@yquem.inria.fr In-Reply-To: <1201537038-sup-3774@ausone.inria.fr> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [Caml-list] [OSR] OCaml Standard Recommandation Process Date: Tue, 29 Jan 2008 02:51:14 -0500 References: <200801281204.00689.jon@ffconsultancy.com> <479DE545.9050306@janestcapital.com> <200801281525.12651.jon@ffconsultancy.com> <20080128.170610.265034237530039453.Christophe.Troestler+ocaml@umh.ac.be> <1201537038-sup-3774@ausone.inria.fr> X-Mailer: Apple Mail (2.915) X-Spam: no; 0.00; ocaml:01 christophe:01 troestler:01 ocaml's:01 translated:01 pervasives:01 deallocation:01 deallocated:01 28,:98 20,:98 wrote:01 wrote:01 caml-list:01 argument:02 binding:02 On 2008-01-28, at 11:20, Nicolas Pouillard wrote: > Excerpts from christophe.troestler+ocaml's message of Mon Jan 28 =20 > 17:06:10 +0100 2008: >> > >> On Mon, 28 Jan 2008 15:25:12 +0000, Jon Harrop wrote: >> >>> So you write a "use" binding: >>> >>> let read_first_line file =3D >>> use ch =3D open_in file in >>> input_line ch >>> >>> and it gets translated into: >>> >>> let read_first_line file =3D >>> let ch =3D open_in file in >>> try input_line ch finally >>> ch#dispose >>> >>> where the "dispose" method that was automatically inserted at the =20= >>> end of the >>> scope of the "use" binding calls "close_in" in this case to =20 >>> deallocate the >>> external resource (a file handle in this case but it could be =20 >>> anything with a >>> dispose method). >> >> What is wrong with >> >> let read_first_line file =3D >> with_open_in file begin fun ch -> >> input_line ch >> end > > This code has nothing wrong but with_open_in (even if it's very =20= > useful) is > not resource safe. This is because the in_channel can escape it's =20 > scope. > > | let ch =3D with_open_in file (fun x -> x) in > | input_line ch > > This program is obviously wrong but still show that with_open_in is =20= > not safe. This argument applies equally to Pervasives.close_in. Allowing the =20 programmer to control the deallocation of external resources is much =20 more important than attempting to prevent her from performing an =20 invalid operation via a deallocated handle. =97 Gordon