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
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 buffer2.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!1.eu.feeder.erje.net!news.swapon.de!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Bob Duff <bobduff@theworld.com>
Newsgroups: comp.lang.ada
Subject: Re: Dynamic allocation in the predefined language environment
Date: Mon, 06 Jul 2015 10:06:10 -0400
Organization: A noiseless patient Spider
Message-ID: <873811cre5.fsf@theworld.com>
References: <559a623d$0$293$14726298@news.sunsite.dk>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org;
 posting-host="b4bd072ef30bb90f74c8989c41f52440";
 logging-data="11904"; mail-complaints-to="abuse@eternal-september.org";
 posting-account="U2FsdGVkX1/bcaYnHXHc6VVRsv2sb+Xz"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
Cancel-Lock: sha1:KvmXjSKlAxRyDn/i/zRYzXnbwKw=
 sha1:shpbV1VmnkTVmCdjdjzdIlq803U=
Xref: number.nntp.giganews.com comp.lang.ada:193943
Date: 2015-07-06T10:06:10-04:00
List-Id: <comp.lang.ada>

Matthias-Christian Ott <ott@mirix.org> writes:

> Unbounded-length strings do not have this limitation but requires
> dynamic memory allocation (or at least I see no other way to implement
> it) which in turn requires error handling of memory allocation errors.
> However, if I'm not mistaken neither Ada 95, nor Ada 2005, nor Ada 2012
> specify how memory allocation errors are to be reported or handled and
> do not allow one to specify the storage pool from which unbounded-length
> strings are allocated. The same seems to be true for other
> unbounded/infinite data-structures.

Yes, the predefined containers packages unfortunately don't allow you to
specify the storage pool.

>...I suppose most implementations will
> raise a Storage_Error exception but the standard does not specify how
> the packages are to implemented so a program could simply crash and
> would still conform to the standard.

No, running out of memory raises Storage_Error.  The implementation
cannot "simply crash".

It's true that the standard does not specify how the packages are
implemented, but they still have to be implemented correctly.
There's nothing in the RM that says they can crash, so they
can't.

- Bob