Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site astrovax.UUCP Path: utzoo!watmath!clyde!floyd!harpo!ulysses!allegra!princeton!astrovax!wls From: wls@astrovax.UUCP (William L. Sebok) Newsgroups: net.unix Subject: Re: Improving C Message-ID: <247@astrovax.UUCP> Date: Wed, 21-Mar-84 16:47:47 EST Article-I.D.: astrovax.247 Posted: Wed Mar 21 16:47:47 1984 Date-Received: Thu, 22-Mar-84 02:27:54 EST References: <17422@sri-arpa.UUCP> <920@dartvax.UUCP> Organization: Princeton Univ. Astrophysics Lines: 18 >> I personally would kill for built-in type checking and array >> bounds checking during the debugging phase of my programs. They could be >> removed after the program reached production quality.... >Dijkstra points out that it is foolish to just use bounds checking during >testing (when you can recover from errors), only to remove the checking >for production runs (when an error becomes a serious thing). > Andy Behrens This is silly. A program that has to handle input from the outside world should do its own checking of the consistency of the input. This should remain during production runs. Other than that one should not have to crucify one's production run on the cross of built-in type checking and array bounds checking. This is the an example of too much of the modern computer theory of "Cpu speed be dammed", that has resulted in so many slow programs and operating systems. -- Bill Sebok Princeton University, Astrophysics {allegra,akgua,burl,cbosgd,decvax,ihnp4,kpno,princeton,vax135}!astrovax!wls