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.1 required=5.0 tests=BAYES_00, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 103376,e6a2e4a4c0d7d8a6 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-21 10:55:05 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.airnews.net!cabal12.airnews.net!usenet From: "John R. Strohm" Newsgroups: comp.lang.ada Subject: Re: status of PL/I as a viable language Date: Fri, 21 Feb 2003 12:48:22 -0600 Organization: Airnews.net! at Internet America Message-ID: <676FD78A4F7BC5E6.0AC31B279C79A77E.45BD70052BD06984@lp.airnews.net> X-Orig-Message-ID: References: <1045839283.86671@master.nyc.kbcfp.com> X-A-Notice: References line has been trimmed due to 512 byte limitation Abuse-Reports-To: abuse at airmail.net to report improper postings NNTP-Proxy-Relay: library2.airnews.net NNTP-Posting-Time: Fri Feb 21 12:53:44 2003 NNTP-Posting-Host: !\]re1k-V_n*$lW (Encoded at Airnews!) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:34366 Date: 2003-02-21T12:48:22-06:00 List-Id: "Hyman Rosen" wrote in message news:1045839283.86671@master.nyc.kbcfp.com... > Ond�ej Tu�n� wrote: > > Not in all cases. Here a complex failure (failure of a Patriot battery) > > was originally caused by a simple overflow error. And as someone already > > pointed out, the complex failure would have never happened if the originating > > simple error was detected and handled properly. > > No. The claim was that the code was written under the assumption > that the overflow would not happen. In such a case, the problem > would never be "handled properly" since proper handling assumes > the belief that the problem can happen. > > There also seems to be the assumption that the overflow error > happens while the battery was just sitting there. It is just > as possible that the overflow manifests only during launch, in > which case causing a reboot wouldn't be very helpful. > > I've mentioned this many times before. Language checks such as > bounds checking, pointer checking, and overflow checking are > fine for testing. But when the application is released, it is > better to disable such checks in cases where continued operation > is important, because it's more likely that a program which > "gets away" with making such an error can keep working, whereas > detecting the error will just blow the program away. One of the luminaries of Computer Science answered that one many years ago. He compared that strategy (specifically with array bounds checking) to wearing a life jacket while playing about inside the sheltered harbor, but discarding the life jacket upon venturing into the open ocean. I think it was Tony Hoare, but it might have been Edsger Dijkstra or Nicklaus Wirth.