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.swapon.de!fu-berlin.de!dotsrc.org!filter.dotsrc.org!news.dotsrc.org!not-for-mail
Date: Tue, 07 Jul 2015 08:46:41 +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>
	<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>
In-Reply-To: <87twthbaia.fsf@theworld.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Message-ID: <559b9160$0$297$14726298@news.sunsite.dk>
Organization: SunSITE.dk - Supporting Open source
NNTP-Posting-Host: 149.222.160.172
X-Trace: news.sunsite.dk
 DXC=5AiNk7SNhE1OVgHIS4l:13YSB=nbEKnk;kEDgFbcTNF=?QB<NW[Fj66@2>B4OQc1?>9S2C>Lo?V]?l=nAi?5m[B3EU7Un5^kXZ9
X-Complaints-To: staff@sunsite.dk
Xref: news.eternal-september.org comp.lang.ada:26675
Date: 2015-07-07T08:46:41+00:00
List-Id: <comp.lang.ada>

On 06/07/15 14:56, Bob Duff wrote:
> 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.

I think that answers the first part of my question adequately, although
its in a surprising part of the specification 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.

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

If you follow the strong exception safety principle from C++, corrupted
data structures should not be a problem. 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. 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.

- Matthias-Christian