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-7-bit
X-Google-Thread: 103376,e6a2e4a4c0d7d8a6
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2003-02-21 10:10:51 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!cyclone.bc.net!sjc70.webusenet.com!sjc72.webusenet.com!news.webusenet.com!newsfeed1.easynews.com!easynews.com!easynews!newshosting.com!news-xfer2.atl.newshosting.com!uunet!dca.uu.net!ash.uu.net!spool0902.news.uu.net!not-for-mail
Date: Fri, 21 Feb 2003 13:10:33 -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>
 <1045839283.86671@master.nyc.kbcfp.com>
 <slrnb5cit4.7us.randhol+news@kiuk0152.chembio.ntnu.no>
 <1045845919.135559@master.nyc.kbcfp.com>
 <slrnb5cp2f.7us.randhol+news@kiuk0152.chembio.ntnu.no>
In-Reply-To: <slrnb5cp2f.7us.randhol+news@kiuk0152.chembio.ntnu.no>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Organization: KBC Financial Products
Message-ID: <1045851033.454019@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: 1045851034  20826 204.253.250.10
Xref: archiver1.google.com comp.lang.ada:34357
Date: 2003-02-21T13:10:33-05:00
List-Id: <comp.lang.ada>

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.

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.

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.