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!.POSTED!not-for-mail
From: Bob Duff <bobduff@theworld.com>
Newsgroups: comp.lang.ada
Subject: Re: Dynamic allocation in the predefined language environment
Date: Tue, 07 Jul 2015 18:32:48 -0400
Organization: A noiseless patient Spider
Message-ID: <87fv4zvbsf.fsf@theworld.com>
References: <559a623d$0$293$14726298@news.sunsite.dk>
	<873811cre5.fsf@theworld.com>
	<559a8d12$0$297$14726298@news.sunsite.dk> <mne2u2$k4b$1@dont-email.me>
	<559a936c$0$292$14726298@news.sunsite.dk>
	<87twthbaia.fsf@theworld.com>
	<559b9160$0$297$14726298@news.sunsite.dk>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org;
 posting-host="7e58ce723f19aac26c67b09fbba12ade";
	logging-data="7049"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX198IaZb5/yQW0dIxXWSKhjO"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
Cancel-Lock: sha1:tkreTAjMPcaxIGUgA35COUQuSWg=
	sha1:sn37pcOmejhbZ53S0eUocA4hUsw=
Xref: news.eternal-september.org comp.lang.ada:26694
Date: 2015-07-07T18:32:48-04:00
List-Id: <comp.lang.ada>

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

> On 06/07/15 14:56, Bob Duff wrote:
>> 6   The execution of any construct raises Storage_Error if there is
>> insufficient storage for that execution. The amount of storage needed for the
>> execution of constructs is unspecified.
>
> I think that answers the first part of my question adequately, although
> its in a surprising part of the specification...

Well, it's hard to know where to put a rule that applies to pretty-much
every feature of the language.  I wouldn't want to duplicate it
in every section.  You were wondering about Unbounded_Strings, if
I recall correctly.  But I wouldn't want to say (in the section on
Unbounded_Strings) "operations in this package raise Storage_Error
if they run out of memory, and it's implementation dependent whether
they do", because there's nothing special about Unbounded_Strings
in that regard.

Perhaps Storage_Error should get its own section.  But with the language
as it is, it would be a pretty short section.  (I'd actually like to
add some functionality: a way to ensure that certain procedures
do NOT run out of memory.)

>... and the "any construct" is
> a bit ambiguous because it's in the dynamic semantics section of
> exception declarations but seems to refer to any construct in the language.

It says "execution of...", so it applies only to those constructs that
are executed (which includes "evaluated" and "elaborated").  Yes, that's
pretty-much "any construct".

And for sure it belongs under Dynamic Semantics, because it happens at
run time.

> If you follow the strong exception safety principle from C++, corrupted
> data structures should not be a problem.

I don't see how.  Storage_Error as defined by the language is like an
asynchronous interrupt.  When programming with asynchronous interrupts,
you need a way to disable interrupts in usually-short sections of code.
When programming with Storage_Error, you need a way to "disable" running
out of memory.  Ada lacks such a feature (and so does every other
programming language I know).

>...However, you can only do this
> in code that is under your control.
>
> You can somewhat avoid Storage_Error exception while handling
> Storage_Error exceptions by having "spare" memory that you free directly
> after the exception handler is invoked.

Yes, but Storage_Error is raised when running out of stack memory as
well as heap/pool memory.  Stack memory is the more "interesting" issue,
IMHO.  Imagine a "when Storage_Error" handler that simply prints a
message "Memory exhausted while processing line N of the input".
No heap-allocation involved, but in theory it can still raise
Storage_Error.

>...Otherwise there are many
> application-specific possibilities on how to deal with memory allocation
> errors in a spectrum ranging from simply aborting to degradation of
> service/user experience.

- Bob