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,FREEMAIL_FROM
	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.224.72.199 with SMTP id n7mr4116402qaj.5.1355571524857;
        Sat, 15 Dec 2012 03:38:44 -0800 (PST)
Received: by 10.49.75.195 with SMTP id e3mr1462190qew.24.1355571524842; Sat,
 15 Dec 2012 03:38:44 -0800 (PST)
Path: 
 k2ni7qap.0!nntp.google.com!fc2no896522qab.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Sat, 15 Dec 2012 03:38:44 -0800 (PST)
In-Reply-To: <565c0f25-e620-4875-9248-2371a874d345@googlegroups.com>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=91.7.35.63;
 posting-account=rmHyLAoAAADSQmMWJF0a_815Fdd96RDf
NNTP-Posting-Host: 91.7.35.63
References: <f7a79646-eb34-42c6-b1df-ccbb8c59437f@googlegroups.com>
 <7ad8ab3a-2a17-44d0-a64f-4cfb1288dc1c@googlegroups.com>
 <565c0f25-e620-4875-9248-2371a874d345@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <1d71f931-42ff-45aa-8ad2-69cae4980917@googlegroups.com>
Subject: Re: Question about library-level functions
From: AdaMagica <christ-usch.grein@t-online.de>
Injection-Date: Sat, 15 Dec 2012 11:38:44 +0000
Content-Type: text/plain; charset=ISO-8859-1
Date: 2012-12-15T03:38:44-08:00
List-Id: <comp.lang.ada>

> As a result, lifetime.Finalize was called twice.
> % ./main
> before
> Initialize (0000000100100090)
> Finalize (0000000100100090)
> lifetime
> Finalize (0000000100100090)
> after

 Hm, I'm no lnaguage lawer, but this looks wrong to me.

> > Finalize may not be called in Alloc,  
> Surely, lifetime.Finalize may be called in 'Alloc'.
>
> The backtrace of gdb is:
>
> #0  lifetime__finalize__2 (object=) at lifetime.adb:7
> #1  0x0000000100001a9c in lifetime__tFD () at lifetime.adb:4
> #2  0x000000010000da39 in system__finalization_masters__finalize (master=) at s-finmas.adb:241
> #3  0x00000001000026d8 in _ada_alloc () at alloc.adb:5
> #4  0x00000001000028f2 in _ada_main () at main.adb:11

Don't know what's happening here...

> > since the object must be created in place
> > (it's limited - there cannot be an intermediate object as in the unlimited 
> > case). 
>
> lifetime.T is limited. However, an access value of it is not limited.

Irrelevant, since it's an object of type T that's finalized here at the end of the lifetime of the corresponding access type.

> Perhaps AARM 7.6.1 says the anonymous access type belongs to innermost master.
> The master is usually in the package and lets objects live long time.
> I imagine, if a function is library-level, there is no place which it
> puts the master, so the master is inside of the function...???

Hm, the master of type A is the access block.

But I'm not sure who the master is of the anonymous access type declared with function Alloc. It should be the environment task, just as that is ultimately the master of any library unit (be it a package or a subprogram).

In effect, I do not really understand what is happening here...