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-Thread: a07f3367d7,2153d570c2f03e29
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.68.202.68 with SMTP id kg4mr2857964pbc.3.1355682669465;
        Sun, 16 Dec 2012 10:31:09 -0800 (PST)
Path: 
 s9ni48630pbb.0!nntp.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: Question about library-level functions
Date: Sun, 16 Dec 2012 18:31:08 +0000
Organization: A noiseless patient Spider
Message-ID: <ly38z5zw5v.fsf@pushface.org>
References: <f7a79646-eb34-42c6-b1df-ccbb8c59437f@googlegroups.com>
	<ly7goiz60i.fsf@pushface.org>
	<a7a82a85-48e4-4ded-b090-06f62bd3b0b6@googlegroups.com>
Mime-Version: 1.0
Injection-Info: mx04.eternal-september.org;
 posting-host="2a5d6fb105b6730bdbc5ec48c6e18f59";
	logging-data="26909"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX19ez87i3vLY1AAPvX2DLnP3YtjC1QBEFsg="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (darwin)
Cancel-Lock: sha1:IaF+R+wv1E12qlQYhLZYf/zmxpI=
	sha1:cCyNNgKOBBIVQTeTdBFyn0kwz/U=
Content-Type: text/plain
Date: 2012-12-16T18:31:08+00:00
List-Id: <comp.lang.ada>

AdaMagica <christ-usch.grein@t-online.de> writes:

> On Sunday, December 16, 2012 10:43:41 AM UTC+1, Simon Wright wrote:
>> ytomino writes:
>>
>> > function alloc return access lifetime.T is
>> > begin
>> >    return new lifetime.T'(lifetime.Create);
>> >    -- lifetime.Finalize may be called here
>> > end alloc;
>>
>> I think that what's happening is that a (limited) temporary lifetime.T
>> object is created (on the heap, or perhaps the secondary stack). Its
>> access is taken for the return value, and then (because we're leaving
>> the scope) it gets finalized.
>
> Looks like so, but IMHO this is illegal. A limited object must be
> created in-place. (Of course an implementation can do as it likes and
> create first a temporary object, then copy it to the final one and
> finalize the temporary *if* the result is as though it was created
> in-place. But here, it seems like the same object is finalized twice.)
>
> What may be temporary and copied it the access value and not the
> accessed object. It's standard to create an object via an access and
> return the latter - the object must not be finalized, of course.
>
> Creating via anonymous access is evil - how can ou ever deallocate it?
> This should be verboten by the language.

OP is quite right that the code behaves properly if alloc() is declared
in a package, and misbehaves when alloc() is declared at library
level. I think this has to be a bug.

Who's going to report it?