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=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,6c7dea22b75ba442
X-Google-Attributes: gid103376,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news1.google.com!news.glorb.com!newscon02.news.prodigy.net!prodigy.net!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail
From: Robert A Duff <bobduff@shell01.TheWorld.com>
Newsgroups: comp.lang.ada
Subject: Re: ada compiler?
Date: Wed, 28 Nov 2007 19:41:57 -0500
Organization: The World Public Access UNIX, Brookline, MA
Message-ID: <wcc3aup3msq.fsf@shell01.TheWorld.com>
References: <TYbZi.77377$kj1.12383@bgtnsc04-news.ops.worldnet.att.net>
 <QPednZmRA_Te8KjanZ2dnUVZ_jednZ2d@comcast.com>
 <IooZi.12685$if6.3756@bgtnsc05-news.ops.worldnet.att.net>
 <uklh05-6gt.ln1@newserver.thecreems.com>
 <lvsZi.13247$if6.1368@bgtnsc05-news.ops.worldnet.att.net>
 <1194747665.6151.31.camel@K72> <_evZi.177931$Xa3.50640@attbi_s22>
 <87hcjq46t4.fsf@ludovic-brenta.org> <yger6ite2fu.fsf@hugsarin.dmusyd.edu>
 <473abc9d$0$13104$9b4e6d93@newsspool2.arcor-online.net>
 <1195035988.599522.87580@50g2000hsm.googlegroups.com>
 <1195043147.1007.263.camel@kartoffel>
 <1195052954.315227.220840@o3g2000hsb.googlegroups.com>
 <1195056238.1007.317.camel@kartoffel>
 <1195058211.682783.288340@d55g2000hsg.googlegroups.com>
NNTP-Posting-Host: shell01.theworld.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: pcls6.std.com 1196296922 29294 192.74.137.71 (29 Nov 2007 00:42:02
 GMT)
X-Complaints-To: abuse@TheWorld.com
NNTP-Posting-Date: Thu, 29 Nov 2007 00:42:02 +0000 (UTC)
User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix)
Cancel-Lock: sha1:JCC2IoSj31xUWJ12kQtUDKaXKnk=
Xref: g2news1.google.com comp.lang.ada:18670
Date: 2007-11-28T19:41:57-05:00
List-Id: <comp.lang.ada>

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> Georg Bauhaus wrote:
>> On Wed, 2007-11-14 at 07:09 -0800, Ludovic Brenta wrote:
>> > But if the stack is exhausted or nearly so (perhaps because the last
>> > in a long series of recursive calls raises Storage_Error), chances are
>> > high that the exception handler itself will overflow the stack (e.g.
>> > passing your string "Hey! You!" to a procedure might itself cause a
>> > stack overflow). This, in my view, greatly reduces the benefit of the
>> > exception. Also, what if raising the exception requires some stack
>> > space? Maybe I should have said that explicitly.
>>
>> No, these are matters of course, and they are mentioned in the RM.
>
> Not really. 11.5(23) says that a stack overflow raises Storage_Error
> but, since the stack has overflowed, I'm not convinced that the
> exception can still be raised, propagated and handled properly. The RM
> is silent about that part and I believe this is an implementation
> issue.

The RM requires that Storage_Error be raised.  So the implementation
must have a little bit of reserve stack space -- enough to do the raise
S_E, and then jump to whatever handler applies.  The stack is normally
chopped back when jumping to the handler, but there is no guarantee (in
the RM) that there's enough stack space to do whatever the handler does.
The handler might raise S_E itself.

- Bob