From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,13d6cd0af0d0d769
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1995-03-24 09:30:06 PST
Path: 
 nntp.gmd.de!stern.fokus.gmd.de!ceres.fokus.gmd.de!zib-berlin.de!Germany.EU.net!wizard.pn.com!sundog.tiac.net!news.kei.com!news.mathworks.com!news2.near.net!news3.near.net!noc.near.net!eisner!kilgallen
From: kilgallen@eisner.decus.org (Larry Kilgallen, LJK Software)
Newsgroups: comp.lang.ada
Subject: Re: Does memory leak?
Message-ID: <1995Mar24.123006.9471@eisner>
Date: 24 Mar 95 12:30:06 -0500
References: <3kopao$ekg@nef.ens.fr> <hbaker-2303951759400001@192.0.2.1>
Organization: DECUServe
Date: 1995-03-24T12:30:06-05:00
List-Id: <comp.lang.ada>

In article <hbaker-2303951759400001@192.0.2.1>, hbaker@netcom.com (Henry Baker) writes:

> Most serious Ada compilers try pretty hard not to leak from internal leaks. 
> However, objects that you allocate yourself with 'new' are considered your
> problem.  Huge amounts of network, conference and newsletter bandwidth have been
> wasted on trying to get around the fact that Ada doesn't provide a built-in
> solution to this problem.

>From the Ada83 manual "An implementation may (but need not) reclaim the
storage occupied by an object created by an allocator, once this object
has become inaccessible."

The next section describes the CONTROLLED pragma to forbid implementations
from reclaiming memory except when leaving the innermost "block statement,
subprogram body or task body" enclosing the type declaration.

Is the complaint that Ada should force implementors to reclaim storage,
or that when the CONTROLLED pragma is not used, implementations should
take a less conservative approach than waiting to exit the scope of the
type declaration?