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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e6a2e4a4c0d7d8a6 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-21 10:38:40 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsmi-us.news.garr.it!NewsITBone-GARR!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!colt.net!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed1.e.nsc.no!nsc.no!nextra.com!uio.no!ntnu.no!not-for-mail From: Preben Randhol Newsgroups: comp.lang.ada Subject: Re: status of PL/I as a viable language Date: Fri, 21 Feb 2003 18:38:40 +0000 (UTC) Organization: Norwegian university of science and technology Message-ID: References: <3E51908E.9CCA3412@adaworks.com> <8Gh4a.7455$_c6.743959@newsread2.prod.itd.earthlink.net> <3E51ABCE.5491B9A2@adaworks.com> <3E5273DE.2050206@cox.net> <3E531E6F.BDFB2599@adaworks.com> <3E546C45.4010406@cox.net> <3E54F926.441D5BB5@adaworks.com> <1045763933.848350@master.nyc.kbcfp.com> <42EA55F4BE83950E.F1DA277C2FDC157B.C804C1C52FE95D65@lp.airnews.net> <1045769690.126389@master.nyc.kbcfp.com> <2lb33b.7d6.ln@jellix.jlfencey.com> <1045772065.590669@master.nyc.kbcfp.com> <1045839283.86671@master.nyc.kbcfp.com> <1045845919.135559@master.nyc.kbcfp.com> <1045851033.454019@master.nyc.kbcfp.com> NNTP-Posting-Host: kiuk0152.chembio.ntnu.no X-Trace: tyfon.itea.ntnu.no 1045852720 21622 129.241.83.78 (21 Feb 2003 18:38:40 GMT) X-Complaints-To: usenet@itea.ntnu.no NNTP-Posting-Date: Fri, 21 Feb 2003 18:38:40 +0000 (UTC) User-Agent: slrn/0.9.7.4 (Linux) Xref: archiver1.google.com comp.lang.ada:34360 Date: 2003-02-21T18:38:40+00:00 List-Id: Hyman Rosen wrote: > Preben Randhol wrote: >> You don't want an untreated integer overflow to cause > > the rods to be pulled up causing a new nuclear meltdown. > > You want that the program to catch this error and go > > into a backup/safe-mode program IMHO. > > The problem is that we're talking about unanticipated > situations, so fallback handling is always going to be > iffy. The fallback handling for the Ariane 5 made it > blow up, after all. Which was the correct thing to do! You don't want the rocket to accelerate down and hit your head do you? > I'm saying that things like buffer overruns and bad > memory accesses and to some extent arithmetic overflow > can be limited problems - some bit of memory on the > stack might get clobbered, but then goes away when the > subroutine returns, for example. This means that even > though the program has acted erroneously in programming > language terms, it is still working properly from an > outside point of view - the toaster is still heating > the bread. Heating it until it starts to burn? I guess one see buffer overruns as a limited problem to the computer that was broken into? Well it happened at the university here and 25000 had to change passwords in some hours. > On the other hand, noticing the error will almost > certainly abort the operation, and since we're talking > about unanticipated errors, things may just come to a > halt. Whether this is desirable depends on the application. Well that's why you have: "anticipated the unexpected!" -- Preben Randhol ---------------- http://www.pvv.org/~randhol/ -- "Violence is the last refuge of the incompetent", Isaac Asimov