Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!husc6!XAIT!g-rh
From: g-rh@XAIT.XEROX.COM (Richard Harter)
Newsgroups: comp.lang.c
Subject: Re: Out of range pointers
Message-ID: <34064@XAIT.XEROX.COM>
Date: 30 Sep 88 08:23:22 GMT
References: <867@osupyr.mast.ohio-state.edu> <3200@geac.UUCP> <1430@ficc.uu.net> <1988Sep15.145026.20325@ateng.uucp> <16041@ism780c.isc.com <28227@think.UUCP> <8557@smoke.ARPA> <33666@XAIT.XEROX.COM> <8564@smoke.ARPA> <33789@XAIT.XEROX.COM> <835@proxftl.UUCP>
Reply-To: g-rh@XAIT.Xerox.COM (Richard Harter)
Organization: Xerox Corporation, Cambridge, Massachusetts
Lines: 53

In article <835@proxftl.UUCP> bill@proxftl.UUCP (T. William Wells) writes:
>In article <33789@XAIT.XEROX.COM> g-rh@XAIT.Xerox.COM (Richard Harter) writes:

>:               The question  as I see it is not one of "fixing" caller
>: interface errors -- it is one of handling them gracefully.

>And I see the problem as one of how much code and time one is
>willing to spend on "graceful handling".  As it happens, I
>routinely write code that does not do *any* parameter
>validation.  And my debugged code almost never breaks in a way
>that would have been caught by parameter validation (or, for that
>matter, by most of the other tricks of the robust-is-god school),
>Now, unless the cost of a failing program is fairly high and the
>cost of adding validity checks is low enough, it follows that
>such checks do not belong in my code.  I don't suppose that I am
>really that atypical, so I suppose that the same applies to other
>programmers.  (Note that I am not speaking of checks used during
>the debugging phase; there one needs all the help one can get.
>:-)

	Debugging??!  You mean there are people that actually write
code that has bugs in it?  :-).  As you imply, there are tradeoffs.
Delivered commercial software, real time systems, software with a
lot of users, software in critical applications, and the like have
a high failure cost.  A lot of my work has been in these areas, so
I am biased towards robustness.  There are a lot of situations where
this is not the case.

	As a general remark, once you get past the initial typos,
etc, most errors are the result of lacunae in the specifications
and analysis.  As you suggest, parameter validation is not a high
profit area in the robust software game.  However it is fairly easy
and it mostly can be done in a routine fashion.  It is also part of
a general mind set which asks as a matter of course, "What will happen
if the assumptions made are violated, and what should I do about it?"
It is this mind set and the systematic routine application of this
approach that reduces the likelihood of these pernicious lacunae.
This is more important in large systems.

>:                                       My view is that one should never
>: assume, as a matter of course, that software is correct.

>And my view is that one should balance the cost of software
>failure against the cost of making it less likely to fail.

	Oh, I agree.  And when I write a throwaway program I cut a lot
of corners.  But even then it often pays to be scrupulous -- the routine
error checking makes debugging much more pleasant.
-- 

In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
	Richard Harter, SMDS  Inc.