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!postnews.google.com!d55g2000hsg.googlegroups.com!not-for-mail From: Ludovic Brenta Newsgroups: comp.lang.ada Subject: Re: ada compiler? Date: Wed, 14 Nov 2007 08:36:51 -0800 Organization: http://groups.google.com Message-ID: <1195058211.682783.288340@d55g2000hsg.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> <1195056238.1007.317.camel@kartoffel> NNTP-Posting-Host: 32.58.34.227 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1195058211 25245 127.0.0.1 (14 Nov 2007 16:36:51 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 14 Nov 2007 16:36:51 +0000 (UTC) In-Reply-To: <1195056238.1007.317.camel@kartoffel> User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1,gzip(gfe),gzip(gfe) X-HTTP-Via: 1.1 SEVPXS01 Complaints-To: groups-abuse@google.com Injection-Info: d55g2000hsg.googlegroups.com; posting-host=32.58.34.227; posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0 Xref: g2news1.google.com comp.lang.ada:18379 Date: 2007-11-14T08:36:51-08:00 List-Id: 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. > 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. The gnat package in Debian is for mundane programs; if you write safety-critical software, you use a supported and certified compiler. So, enabling -fstack-check by default is a viable option that I am considering. Like I said earlier, it would still be possible to disable stack checking by saying -fno-stack-check explicitly. You say that -fstack-check and the Storage_Error allow you to try and "recover" but I'm not convinced that recovery is possible after a stack overflow. In fact, I'm not even convinced that exception propagation can be relied on after a stack overflow. Heap overflows are different, of course, and are not affected by -fstack-check. Your latest example was a heap overflow and therefore off-topic. Does someone here know GNAT internals in sufficient detail as to enlighten us? Also can someone explain what "reliable" stack checking is in GNAT parlance? -- Ludovic Brenta.