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: Mon, 06 Jul 2015 10:56:13 -0400
Organization: A noiseless patient Spider
Message-ID: <87twthbaia.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>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org;
 posting-host="b4bd072ef30bb90f74c8989c41f52440";
	logging-data="29282"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+P2lKRqOat3lRPaUbpFG25"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
Cancel-Lock: sha1:ojsF+mOZiXh5nvNkHGHiY7rfp/M=
	sha1:gXGLAK1LH/QPnT2DlNrOWmp19FI=
Xref: news.eternal-september.org comp.lang.ada:26642
Date: 2015-07-06T10:56:13-04:00
List-Id: <comp.lang.ada>

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

> Then to finish this discussion: If it is required to raise
> Storage_Error, then it should be in the standard.

It is in the standard.  See 11.1(6):

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.

>... There are only a
> handful of Ada compilers which most likely all raise Storage_Error but I
> think the history of C shows that if there is an ambiguity in the
> standard, both compiler writers and software developers will interpret
> it differently, so that both different compilers and the assumptions of
> software developers about these compilers will differ.

Yes, all true, but 11.1(6) seems pretty unambiguous to me.

Actually handling Storage_Error can be tricky, though.  For one thing,
in theory, the handler itself could raise Storage_Error, defeating the
purpose.  More importantly, since Storage_Error can be raised by
anything, it is essentially asynchronous with the rest of the program,
so can leave data structures in a corrupted state.

- Bob