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=-2.9 required=3.0 tests=BAYES_00,NICE_REPLY_A
	autolearn=ham autolearn_force=no version=3.4.6
Path: eternal-september.org!reader02.eternal-september.org!news.szaf.org!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Custom Storage Pool questions
Date: Sat, 18 Sep 2021 00:17:50 +0300
Organization: Tidorum Ltd
Message-ID: <iqkevvFr27rU1@mid.individual.net>
References: <e3c5c553-4a7f-408a-aaa7-60ec0b70202dn@googlegroups.com>
 <ly5yv1bxgy.fsf@pushface.org> <shtg99$tgd$1@gioia.aioe.org>
 <lywnnha7y1.fsf@pushface.org>
 <1d2551f4-8189-44ec-a54d-4a56a672bedcn@googlegroups.com>
 <c2d59417-398f-42a0-ab4b-b4f947325be0n@googlegroups.com>
 <si26q3$13l1$1@gioia.aioe.org> <lyo88r9e99.fsf@pushface.org>
 <si2ud7$fv2$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net Ycc1+TDostMjOK8zyo+BuQP1XG9m4i3Mf1an1etm+EzJjh0MSi
Cancel-Lock: sha1:53dtMSP7bUXxE01lXKLkFqmR+ak=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
 Gecko/20100101 Thunderbird/78.13.0
In-Reply-To: <si2ud7$fv2$1@gioia.aioe.org>
Content-Language: en-US
Xref: reader02.eternal-september.org comp.lang.ada:62769
List-Id: <comp.lang.ada>

On 2021-09-17 23:39, Dmitry A. Kazakov wrote:
> On 2021-09-17 21:46, Simon Wright wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>
>>> Nope, especially because the issue with X'Address being unusable for
>>> memory pool developers is a long standing painful problem that need to
>>> be resolved. That will never happen until a measurable group of people
>>> start asking questions. So you are doubly welcome.
>>
>> There are two attributes that we should all have known about,
>> Descriptor_Size[1] (bits, introduced in 2011) and Finalization_Size[2]
>> (storage units, I think, introduced in 2017)
> 
> They are non-standard and have murky semantics I doubt anybody really 
> cares about.
> 
> What is needed is the address passed to Deallocate should the object be 
> freed = the address returned by Allocate. Is that too much to ask?


That is already required by RM 13.11(21.7/3): "The value of the 
Storage_Address parameter for a call to Deallocate is the value returned 
in the Storage_Address parameter of the corresponding successful call to 
Allocate."

The "size" parameters are also required to be the same in the calls to 
Deallocate and to Allocate.


> BTW, finalization lists (#2) should have been removed from the language 
> long ago. 


Huh? Where does the RM _require_ finalization lists? I see them 
mentioned here and there as a _possible_ implementation technique, and 
an alternative "PC-map" technique is described in RM 7.6.1 (24.r .. 24.t).