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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!ads.com!bhanafee
From: bhanafee@ADS.COM (Brian Hanafee)
Newsgroups: comp.lang.ada
Subject: Re: Storage Error
Message-ID: <+}&^%H#@ads.com>
Date: 13 Nov 90 03:51:28 GMT
References: <108637@convex.convex.com>
Sender: usenet@ads.com (USENET News)
Organization: Advanced Decision Systems, Mtn. View, CA (415) 960-7300
List-Id: <comp.lang.ada>

In article <108637@convex.convex.com> gargulak@mozart.convex.com (Tom Gargulak) writes:
>I got the following example from the book by Barnes (pg. 183).  Barnes 
>claims that this program should raise the STORAGE_ERROR exception
>and I agree due to 11.4.1(10) in the LRM.  A colleague believes that
>Barnes is mistaken and that it would be acceptable for the program
>to run forever.  He claims it depends how the stack is implemeted.
[stuff deleted]
>
>procedure P is
>begin
>  P;
>exception
>  when others =>
>    P;
>end;


I believe that there are three possible (implementation dependent)
behaviours for this program:

Case 1:
  The compiler generated code does not require any new storage for
each new invocation of P.  In this case, the program will not run out
of storage, and may acceptably run forever.

Case 2:
  If the implementation requires that each invocation of P uses some
new storage (such as stack space), then eventually an invocation of P
will cause a STORAGE_ERROR.  The invocation of P from the handler will
(presumably) cause a *new* STORAGE_ERROR to be raised.  Under
11.4.1(10), this exception will cause the program to raise
STORAGE_ERROR.

Case 3:
  After STORAGE_ERROR is first raised, the program could detect that the
invocation of P from the handler is erroneous, and raise PROGRAM_ERROR
instead.


------------------------------------------------------------------------
Brian Hanafee                    | **Standard Disclaimer**
Advanced Decision Systems        |
------------------------------------------------------------------------