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.4 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE autolearn=disabled version=3.1.3 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 8E136BC6B for ; Mon, 10 Dec 2007 12:57:05 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAOO3XEfUGyojimdsb2JhbACBWo4KAQEBCAIIIgc X-IronPort-AV: E=Sophos;i="4.23,276,1194217200"; d="scan'208";a="6658692" Received: from smtp5-g19.free.fr ([212.27.42.35]) by mail3-smtp-sop.national.inria.fr with ESMTP; 10 Dec 2007 12:57:05 +0100 Received: from smtp5-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp5-g19.free.fr (Postfix) with ESMTP id 17B2E3F61CD; Mon, 10 Dec 2007 12:57:05 +0100 (CET) Received: from Llea.celt.neu (ron34-3-82-236-236-194.fbx.proxad.net [82.236.236.194]) by smtp5-g19.free.fr (Postfix) with ESMTP id E5C093F6199; Mon, 10 Dec 2007 12:57:04 +0100 (CET) Received: from Llea.celt.neu (localhost [127.0.0.1]) by Llea.celt.neu (8.14.1/8.13.8) with ESMTP id lBAC3DCk001591; Mon, 10 Dec 2007 13:03:13 +0100 (CET) (envelope-from michael.le_barbier@laposte.net) Received: (from michael@localhost) by Llea.celt.neu (8.14.1/8.13.8/Submit) id lBAC3CDf001590; Mon, 10 Dec 2007 13:03:12 +0100 (CET) (envelope-from michael.le_barbier@laposte.net) X-Authentication-Warning: Llea.celt.neu: michael set sender to michael.le_barbier@laposte.net using -f To: Fabrice Pardo Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Ask for a more efficient way to deallocate memory (full version) References: <39980.81.57.198.61.1197236388.squirrel@webmail.lpn.cnrs.fr> <95513600712091355j35c4fa65g40bbfce02303796a@mail.gmail.com> <475D2210.70708@Lpn.cnrs.fr> From: michael.le_barbier@laposte.net (=?iso-8859-15?Q?Micha=EBl?= Le Barbier) Date: Mon, 10 Dec 2007 13:03:12 +0100 In-Reply-To: <475D2210.70708@Lpn.cnrs.fr> (Fabrice Pardo's message of "Mon\, 10 Dec 2007 12\:25\:04 +0100") Message-ID: <86zlwi92pr.fsf@Llea.celt.neu> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable X-Spam: no; 0.00; allocating:01 opendir:01 trivial:01 deallocation:01 unix:01 heap:01 caml-list:01 functions:01 functions:01 writes:01 api:02 external:03 deallocate:03 module:03 module:03 Fabrice Pardo writes: > I have a new question now: > What is the drawback if we keep hidden > unsecure external functions (allocating out of the heap > resources, as Unix.opendir), > only publishing secure functions as "with_dir" ? > Of course, I mean other drawback than changing the API. A drawback is that careful management of these ressources is no more possible. If the choices made by module designer to ensure security do not fit well your problem, you are left with no option other than writing poorly behaving applications. In contrast, given a module that delegates ressource management to its users, it is fairly trivial to wrap modules's functionnalitites into a module that automatizes ressource management in a way that will fit many uses. One would write an `EasyLazyUnix', `CookedUnix' or `UnixChest' module with automatic deallocation of ressources. --=20 Cordialement, Micha=EBl LB