Out of range pointers

[Richard Harter]

In article <8564 at smoke.ARPA> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <33666 at XAIT.XEROX.COM> g-rh at XAIT.Xerox.COM (Richard Harter) writes:
>>one checks the input for validity.  If there is trouble in your routine,
>>that's your problem.  But if you don't check your input and it violates
>>your interface assumptions anything can happen.

>You cannot fix the caller's violation of the interface spec in the called
>routine.

>It often pays to perform thorough parameter validation while debugging an
>application, but you should not rely on such micro-tests for robustness.

We seem to have strayed out of specifics into the area of general software
methodology.  The question  as I see it is not one of "fixing" caller
interface errors -- it is one of handling them gracefully.  In robust code
the effects of an error are predictable and there are damage control measures;
in fragile code the effects of an error are unpredictable and may be
catastrophic.  I would say that it pays to perform parameter validation,
not merely while debugging an application, but at all times and that the
specifications should include, as a matter of course, the actions to be
taken when parameters are not valid.  My view is that one should never
assume, as a matter of course, that software is correct.
-- 

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