Out of range pointers
Richard Harter
g-rh at XAIT.XEROX.COM
Sun Sep 25 08:12:17 AEST 1988
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.
More information about the Comp.lang.c
mailing list