Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!gatech!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: <33666@XAIT.XEROX.COM> Date: 22 Sep 88 08:56:51 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> Reply-To: g-rh@XAIT.Xerox.COM (Richard Harter) Organization: Xerox Corporation, Cambridge, Massachusetts Lines: 21 In article <8557@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) writes: >In article <33547@XAIT.XEROX.COM> g-rh@XAIT.Xerox.COM (Richard Harter) writes: >>However it would be very nice if there were a library routine that would >>tell you whether a pointer was legal or not. >I think if your code has to worry about this, it is ALREADY in trouble. >Pointers should come in two flavors: null (which is easy to test) and >valid (which you should be able to assume when non-null). Oh come on now, my code is never in trouble. What, never? But it is just this kind of thinking "you should be able to assume" that leads to bug-ridden code which lacks robustness. If one is writing a service routine one doesn't blissfully assume that the caller hasn't blown it; 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. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.