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!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.cw.net!cw.net!news-FFM2.ecrc.de!uio.no!newsfeed1.fi.sn.net!fi.sn.net!newsfeed2.fi.sn.net!news.song.fi!not-for-mail
Date: Wed, 14 Nov 2007 23:31:57 +0200
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.7.8) Gecko/20060628 Debian/1.7.8-1sarge7.1
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: ada compiler?
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>
In-Reply-To: <1195052954.315227.220840@o3g2000hsb.googlegroups.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <473b58af$0$27815$39db0f71@news.song.fi>
Organization: TDC Song Internet Services
NNTP-Posting-Host: laku61.adsl.netsonic.fi
X-Trace: 1195071664 news.song.fi 27815 81.17.205.61:32975
X-Complaints-To: abuse@song.fi
Xref: g2news1.google.com comp.lang.ada:18390
Date: 2007-11-14T23:31:57+02:00
List-Id: <comp.lang.ada>

Ludovic Brenta wrote:
> On Nov 14, 1:25 pm, Georg Bauhaus <rm.tsoh+bauh...@maps.futureapps.de>
> wrote:
> 
>>On Wed, 2007-11-14 at 02:26 -0800, Ludovic Brenta wrote:
>>
>>> Also, if a stack overflow results in
>>>a SEGV (instead of Storage_Error), I don't clearly see the functional
>>>difference i.e. the stack overflow gets caught either way.
>>
>>But who catches? A player in the game (Ada partition),
>>or someone in the stadium (OS)?
> 
> 
> 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.

My wishlist for stack checking support in Ada compilers:

Storage_Error should be raised a bit before the stack is fully 
exhausted. The amount of "reserve" stack-space left at that point 
should be configurable by an option or an environment variable to 
an (application-specific) value that lets the exception be raised 
and handled.

While the exception is being propagated and handled (that is, while 
it is possible to say "raise;") the application should be able to 
use the reserve stack capacity (with possibly a Segmentation 
Violation if the reserve capacity is exhausted).

Normal checking rules (respecting the reserve capacity) should 
return into force when the exception has been handled (when it is 
no longer possible to reraise the exception).

But I have no idea how hard that would be to implement...

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .