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.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: 
 buffer1.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!goblin2!goblin.stu.neva.ru!newsfeed1.swip.net!81.169.171.211.MISMATCH!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: "G.B." <bauhaus@futureapps.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Dynamic allocation in the predefined language environment
Date: Mon, 6 Jul 2015 15:04:35 +0200
Organization: A noiseless patient Spider
Message-ID: <mnduaf$10f$1@dont-email.me>
References: <559a623d$0$293$14726298@news.sunsite.dk>
Reply-To: nonlegitur@futureapps.de
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 6 Jul 2015 13:03:11 +0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="b96887e80893c84a90c3007226ca0d1c";
 logging-data="1039"; mail-complaints-to="abuse@eternal-september.org";
 posting-account="U2FsdGVkX1+GPOHhYix0J5ZXaVBOsDmMgErotjpmrNM="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
 Gecko/20100101 Thunderbird/38.0.1
In-Reply-To: <559a623d$0$293$14726298@news.sunsite.dk>
Cancel-Lock: sha1:CXx72tOe4L+Yc/947bw0UeFVzJk=
Xref: number.nntp.giganews.com comp.lang.ada:193941
Date: 2015-07-06T15:04:35+02:00
List-Id: <comp.lang.ada>

On 06.07.15 13:13, Matthias-Christian Ott wrote:

> 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.

I think that LRM 13.11 might apply here (coming from LRM 4.8),

"If Storage_Pool is not specified for a type defined by an
  access_to_object_definition, then the implementation chooses
  a standard storage pool for it in an implementation-defined
  manner.  In this case, the exception Storage_Error is raised
  by an allocator if there is not enough storage."

A handler then, if possible, could be of the kind that
does not require additional resources for its execution.
It might be more tricky to use one with tasks, but IIUC,
one can attach termination handlers.