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=unavailable autolearn_force=no version=3.4.4
X-Received: by 10.107.173.29 with SMTP id w29mr2125944ioe.31.1476892432322;
        Wed, 19 Oct 2016 08:53:52 -0700 (PDT)
X-Received: by 10.157.41.106 with SMTP id d97mr1157849otb.6.1476892432287;
 Wed, 19 Oct 2016 08:53:52 -0700 (PDT)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!e187no312836itc.0!news-out.google.com!w143ni791itb.0!nntp.google.com!66no316184itl.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Wed, 19 Oct 2016 08:53:51 -0700 (PDT)
In-Reply-To: <nu5ev1$lgp$1@gioia.aioe.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=74.51.4.208;
 posting-account=7Oy7OQoAAABhVYFOo553Cn1-AaU-bSfl
NNTP-Posting-Host: 74.51.4.208
References: <nu50ch$1q33$1@gioia.aioe.org> <nu54u2$2uq$1@gioia.aioe.org>
 <nu5ev1$lgp$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <97d605d4-42e7-4706-96ef-0253be53a81a@googlegroups.com>
Subject: Re: Bug in GNAT? - Max_size_in_storage_elements insufficient
From: Eryndlia Mavourneen <eryndlia@gmail.com>
Injection-Date: Wed, 19 Oct 2016 15:53:52 +0000
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Xref: news.eternal-september.org comp.lang.ada:32138
Date: 2016-10-19T08:53:51-07:00
List-Id: <comp.lang.ada>

On Tuesday, October 18, 2016 at 10:26:28 AM UTC-5, Vratislav Podzimek wrote=
:
> Well, then it's at least a bug in [Barnes] because there's an example=20
> like the above ones just with a simpler type. But I still think the idea=
=20
> here is/was to provide enough space for N items of some type. That's what=
=20
> the 'Max_size_in_storage_elements' attribute should be good for. And=20
> there's no fragmentation nor history of allocation/deallocation in my=20
> case. If I specify I want space for 4 records, I should get space for 4=
=20
> records. Not slightly less due to some hidden, unpredictable overhead.

There is another use for the attribute Max_Size_In_Storage_Elements.  That =
is to allow a dynamic allocation on the stack for an object whose size and =
subtype you may not know until run-time and for mapping using along with us=
ing the 'Address attribute for mapping these subtypes.  This can occur when=
 receiving messages over a communications link or when reading from a loose=
ly-defined file.  This type of thing, otherwise, is not good design and is =
questionable even in this case.=20

-- Eryndlia