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.