Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ncar!husc6!XAIT!g-rh
From: g-rh@XAIT.XEROX.COM (Richard Harter)
Newsgroups: comp.lang.c
Subject: Re: Out of range pointers
Message-ID: <33789@XAIT.XEROX.COM>
Date: 24 Sep 88 22:12:17 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>
Reply-To: g-rh@XAIT.Xerox.COM (Richard Harter)
Organization: Xerox Corporation, Cambridge, Massachusetts
Lines: 27

In article <8564@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) writes:
>In article <33666@XAIT.XEROX.COM> g-rh@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.