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!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!club-internet.fr!feedme-small.clubint.net!newsfeed.freenet.de!newsfeed01.chello.at!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Newsgroups: comp.lang.ada Subject: Re: ada compiler? From: Georg Bauhaus In-Reply-To: <1195052954.315227.220840@o3g2000hsb.googlegroups.com> References: <1194747665.6151.31.camel@K72> <_evZi.177931$Xa3.50640@attbi_s22> <87hcjq46t4.fsf@ludovic-brenta.org> <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> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1195056238.1007.317.camel@kartoffel> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Date: Wed, 14 Nov 2007 17:03:58 +0100 Organization: Arcor NNTP-Posting-Date: 14 Nov 2007 17:02:53 CET NNTP-Posting-Host: c6272ade.newsspool4.arcor-online.net X-Trace: DXC=V=hc3c`U_3Fk:C4l9A;OcO4IUKB6gHc^F<0i=B=kbmW`a1fGGC`2T@AUZfCKCJ_C79An3>A X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:18377 Date: 2007-11-14T17:02:53+01:00 List-Id: 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.