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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,89cbee942992178a
X-Google-Attributes: gid103376,public
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: Deallocating Task objects
Date: 1997/02/18
Message-ID: <E5t7tL.Asu@world.std.com>#1/1
X-Deja-AN: 219661266
References: <01bc1b53$fb0251c0$829d6482@joy.ericsson.se>
 <33086C65.F9F@elca-matrix.ch> <3309C668.7D8E@Sor.psu.edu>
Organization: The World Public Access UNIX, Brookline, MA
Newsgroups: comp.lang.ada
Date: 1997-02-18T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <3309C668.7D8E@Sor.psu.edu>,
Robert L. Spooner <rls19@psu.edu> wrote:
>For Ada 83 some memory had to be kept so that the task attributes such
>as T'terminated could be used.  I don't know enough about Ada (95) yet
>to know if it is still necessary.

The case is where a function returns a task object that is local to the
function.  I believe there was an Ada 83 AI that "clarified" that this
case was erroneous, so that storage for the task could be deallocated
upon leaving the function.  (In the standards business, "clarified" is a
euphemism for "fixing a bug in the language".  ;-))  Unfortunately, this
fix was made after ACVC tests had already forced implementers to keep
that storage around.

In Ada 95, this case raises Program_Error.  The error can actually be
caught at compile time, except in some cases involving generics -- a
good compiler will warn at compile time.

See AARM-6.5(20.a-20.d, 24.a-24.b) for some discussion of this stuff.

- Bob