Re: ada compiler?

["Randy Brukardt" <randy@rrsoftware.com>]

"Ludovic Brenta" <ludovic@ludovic-brenta.org> wrote in message
news:1195058211.682783.288340@d55g2000hsg.googlegroups.com...
> 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.

True enough, but an implementation that couldn't raise and handle
Storage_Error (without any further operations in the handler) would fail the
ACATS (yes, this is tested, and has been all the way back to Ada 83).

One possible reaction is to unwind the broken recursion by putting the
handler outside of the recursive call. In this case, one would expect to
have no trouble handling the exception as much of the stack memory has been
freed before the handler is entered. I think anyone who did that would be on
the phone to their vendor in a hurry if that did not work (and yes, I've
been on the receiving end of such calls).

Formally, *anything* (including "null;") in an Ada program can raise
Storage_Error. But implementations generally take precautions to ensure that
it works as expected, because having the bare minimum implementation is
rarely enough in the real world.

                           Randy.