Re: ada compiler?

[Georg Bauhaus <rm.tsoh+bauhaus@maps.futureapps.de>]

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.

However, I prefer being given a chance to run some emergency code,
even knowing that I cannot in general rely on anything
in the presence of Storage_Error (or exceptions with -O, for that
matter). Perhaps I should mention that the programs that I have
in mind are more mundane than hard real-time control programs.

Thus I can afford more optimistic attempts at recovery,
using exception handling rather than invoking, well, something
outside the program.

I think it is better to try something in case of a detected
error than
- have service personnel (if any) say F,
- pick up the next phone (if any) or micro (if functional),
- call the other end (if someone is there and has a phone/ear~s),
- ...

I could also try to have the operating system (if any; well, we
have Debian in this case) react to the SEGV (if possible)
and trigger something else (if possible; load might be high
already, though, persistance is futile ...)  But, ... I can do that,
too, if the program exits "more normally" as a consequence of
an exception.

Right now I don't remember exactly what happens to files
still open when a Linux Ada executable is brought
to a halt by a segmentation violation. Is it better to exit
"more normally"?

And what is more, the program shown is only trying
to allocate a larger chunk of memory. What should stop
programmers from at least trying to allocate larger objects in
a (more or less) controlled fashion?

A related example:

 declare
    Long_String: String_Access;
 begin
       Long_String := new String'(Lots);

 exception
    when Storage_Error =>
          -- trouble ahead? But anyway, we may be
          -- able to try something else, again.
          -- Maybe decrease Lots.
          ...
  end;

I also remember (vaguely) that in those days (Turbo Pascal?) we were
asked to do something similar, make sure that handlers (of interrupts?)
would not need more storage than was allocated before the program
would start. As the previous program has shown, there is no guarantee
that a simple exception handler must fail in the presence of
Storage_Error.  There are programs where optimism is a necessary
attitude.