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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail
From: Vratislav Podzimek <vratislav.podzimek@gmail.com>
Newsgroups: comp.lang.ada
Subject: Re: Bug in GNAT? - Max_size_in_storage_elements insufficient
Date: Tue, 18 Oct 2016 15:26:25 +0000 (UTC)
Organization: Aioe.org NNTP Server
Message-ID: <nu5ev1$lgp$1@gioia.aioe.org>
References: <nu50ch$1q33$1@gioia.aioe.org> <nu54u2$2uq$1@gioia.aioe.org>
NNTP-Posting-Host: ONPcOm8flCRYsdvOmHwGzA.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT b8fc14e
 git.gnome.org/git/pan2)
X-Notice: Filtered by postfilter v. 0.8.2
Xref: news.eternal-september.org comp.lang.ada:32122
Date: 2016-10-18T15:26:25+00:00
List-Id: <comp.lang.ada>

On Tue, 18 Oct 2016 14:35:15 +0200, Dmitry A. Kazakov wrote:

> On 18/10/2016 13:17, Vratislav Podzimek wrote:
> 
>> Or am I missing something?
> 
> A storage pool requires additional space to organize its structure and
> maintain its state. Depending on the method it is usually impossible to
> estimate the exact number of object  the pool may hold. It depends on
> the individual sizes of the objects, the history of object's allocation
> and deallocation, the history of claiming the memory for the parts of
> the pool from the OS (a pool can be segmented).

Well, then it's at least a bug in [Barnes] because there's an example 
like the above ones just with a simpler type. But I still think the idea 
here is/was to provide enough space for N items of some type. That's what 
the 'Max_size_in_storage_elements' attribute should be good for. And 
there's no fragmentation nor history of allocation/deallocation in my 
case. If I specify I want space for 4 records, I should get space for 4 
records. Not slightly less due to some hidden, unpredictable overhead.