From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 required=3.0 tests=BAYES_00,XPRIO autolearn=no
	autolearn_force=no version=3.4.6
Path: eternal-september.org!reader02.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: On absurdity of collections 7.6.1 (11.1/3)
Date: Thu, 30 Sep 2021 20:37:52 -0500
Organization: JSA Research & Innovation
Message-ID: <sj5oph$qss$1@franka.jacob-sparre.dk>
References: <sj1ah7$7kr$1@gioia.aioe.org> <lybl4bbq19.fsf@pushface.org> <sj1i6g$7hv$1@gioia.aioe.org> <ly35pnawpp.fsf@pushface.org> <sj3r7l$pla$2@gioia.aioe.org>
Injection-Date: Fri, 1 Oct 2021 01:37:53 -0000 (UTC)
Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226";
	logging-data="27548"; mail-complaints-to="news@jacob-sparre.dk"
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246
Xref: reader02.eternal-september.org comp.lang.ada:62909
List-Id: <comp.lang.ada>

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:sj3r7l$pla$2@gioia.aioe.org...
...
> Yes, every general access type that permits instantiation of 
> Unchecked_Dellocation must indicate the target object's pool, directly, 
> e.g. per fat pointer, or indirectly by some other schema. I see nothing in 
> RM that allows a different implementation. But it is could be a bug by 
> omission and I am not a language lawyer anyway.

Each access type has only one pool, and all allocations and deallocations 
for that access type use that pool. You can see at RM 13.11(13) that you can 
retrieve the storage pool of T, that wouldn't be possible if it could have 
multiple pools. Allocation for T uses T'Storage_Pool (RM 13.11(16)), and 
deallocation for T also uses T'Storage_Pool (13.11.2(9/3) - I see this 
wording isn't as clear as it could be, but "the storage_pool" here is the 
one for the type T. It is clear, however, from 13.11.2(16/3) that it is 
erroneous to deallocate an object for some other pool than the pool of the 
access type passed to the instance of Unchecked_Deallocation.

Surely no one would expect the pool to be associated with the object -- it 
would be impossible to interface to C or most other languages that way. Note 
that GNAT insists that all access types are C-compatible.

As I've said repeatedly, if you want the behavior of multiple pools with a 
single access type, you have to use the subpool mechanism somehow.

                          Randy.