Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcnc!gatech!cuae2!ihnp4!inuxc!pur-ee!uiucdcs!uiucdcsb!robison
From: robison@uiucdcsb.cs.uiuc.edu
Newsgroups: comp.lang.misc
Subject: Re: Check the Arg Count
Message-ID: <170500002@uiucdcsb>
Date: Tue, 20-Jan-87 12:16:00 EST
Article-I.D.: uiucdcsb.170500002
Posted: Tue Jan 20 12:16:00 1987
Date-Received: Thu, 22-Jan-87 00:22:37 EST
References: <508@csun.UUCP>
Lines: 31
Nf-ID: #R:csun.UUCP:508:uiucdcsb:170500002:000:1300
Nf-From: uiucdcsb.cs.uiuc.edu!robison    Jan 20 11:16:00 1987


> ... I am not sure about you, but I would rather have a program that runs
> faster, and in one chance in a couple thousand `goes down in flames' than a
> program that runs slower and in one chance in a couple thousand
> says something to the effect: `FATAL: array overflow'...
> Also, I think your analogy is a bit off. `My boats DONT sink',  8->
> therefor, why WASTE money on lifeboats? :-)
> -- 

Suppose your CAD program for nuclear-powered boats has the error-checking
turned off.  So instead of `FATAL: array overflow' some data is corrupted
(without any indication) and you go ahead and build the boat, which 
promptly sinks.

One chance in a couple thousand is not good enough.  I think most of the
checks causing significant slowing could be verified by static analysis
at compile time and the run-time check not inserted.  E.g. some simple
range analysis could show many subscript-checks are provably unnecessary.
Presumably its only a few checks in the inner-most loops that cause the 
program to run signifcantly slower.

There's some papers on range analysis in: 

	Program Flow Analysis: Theory and Applications
	Steven S. Muchnick & Neil D. Jones
	Prentice-Hall, Inc.
	Englewood Cliffs, New Jersey
	1981

Arch D. Robison					robison@uiucdcs
University of Illinois at Urbana-Champaign