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: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!dotsrc.org!filter.dotsrc.org!news.dotsrc.org!not-for-mail
Date: Mon, 06 Jul 2015 14:21:47 +0000
From: Matthias-Christian Ott <ott@mirix.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
 rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Dynamic allocation in the predefined language environment
References: <559a623d$0$293$14726298@news.sunsite.dk>
 <mnduaf$10f$1@dont-email.me>
In-Reply-To: <mnduaf$10f$1@dont-email.me>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Message-ID: <559a8e6b$0$292$14726298@news.sunsite.dk>
Organization: SunSITE.dk - Supporting Open source
NNTP-Posting-Host: 149.222.160.108
X-Trace: news.sunsite.dk
 DXC=4dZ]@C_]hRbHZJdbckJ<MnYSB=nbEKnkkKYaf4:2H0cb?QB<NW[Fj6f@2>B4OQc1?n9S2C>Lo?V]oh5eYG[kWaEhO?<[nB=D]0b
X-Complaints-To: staff@sunsite.dk
Xref: news.eternal-september.org comp.lang.ada:26638
Date: 2015-07-06T14:21:47+00:00
List-Id: <comp.lang.ada>

On 06/07/15 13:04, G.B. wrote:
> 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.

That should work. But what if the implementation does not use access
types or storage pools to implement unbounded-length strings? The
standard simply doesn't specify the behaviour or implementation of the
package with regards to memory management.

- Matthias-Christian