Out of range pointers

[Richard Harter]

In article <835 at proxftl.UUCP> bill at proxftl.UUCP (T. William Wells) writes:
>In article <33789 at XAIT.XEROX.COM> g-rh at 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.