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,FREEMAIL_FROM
	autolearn=ham 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 06:54:46 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp.abs.net!uunet!dca.uu.net!ash.uu.net!spool0900.news.uu.net!reader0902.news.uu.net!not-for-mail
Date: Fri, 21 Feb 2003 09:54:43 -0500
From: Hyman Rosen <hyrosen@mail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.3b) Gecko/20030130
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: status of PL/I as a viable language
References: <mHZ0a.42983$jM5.108891@newsfeeds.bigpond.com>
 <nRg1a.190899$HG.32437469@news4.srv.hcvlny.cv.net>
 <3E51908E.9CCA3412@adaworks.com>
 <8Gh4a.7455$_c6.743959@newsread2.prod.itd.earthlink.net>
 <3E51ABCE.5491B9A2@adaworks.com> <b2spe6$p23$1@helle.btinternet.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> <oprkxqhntnmzo9uz@news.vol.cz>
In-Reply-To: <oprkxqhntnmzo9uz@news.vol.cz>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 8bit
Organization: KBC Financial Products
Message-ID: <1045839283.86671@master.nyc.kbcfp.com>
Cache-Post-Path: master.nyc.kbcfp.com!unknown@nightcrawler.nyc.kbcfp.com
X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/)
NNTP-Posting-Host: 204.253.250.10
X-Trace: 1045839284 reader2.ash.ops.us.uu.net 24011 204.253.250.10
Xref: archiver1.google.com comp.lang.ada:34340
Date: 2003-02-21T09:54:43-05:00
List-Id: <comp.lang.ada>

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.