Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!ukma!uflorida!novavax!proxftl!bill
From: bill@proxftl.UUCP (T. William Wells)
Newsgroups: comp.lang.c
Subject: Re: Out of range pointers
Message-ID: <835@proxftl.UUCP>
Date: 30 Sep 88 05:06:20 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> <33789@XAIT.XEROX.COM>
Reply-To: bill@proxftl.UUCP (T. William Wells)
Organization: Proximity Technology, Ft. Lauderdale
Lines: 56
Summary:
Expires:
Sender:
Followup-To:
Distribution:
Keywords:

In article <33789@XAIT.XEROX.COM> g-rh@XAIT.Xerox.COM (Richard Harter) writes:
: We seem to have strayed out of specifics into the area of general software
: methodology.

Yes, but since C has some specific problems with what you would
like, it is not too far off the subject.

:               The question  as I see it is not one of "fixing" caller
: interface errors -- it is one of handling them gracefully.

And I see the problem as one of how much code and time one is
willing to spend on "graceful handling".  As it happens, I
routinely write code that does not do *any* parameter
validation.  And my debugged code almost never breaks in a way
that would have been caught by parameter validation (or, for that
matter, by most of the other tricks of the robust-is-god school),
Now, unless the cost of a failing program is fairly high and the
cost of adding validity checks is low enough, it follows that
such checks do not belong in my code.  I don't suppose that I am
really that atypical, so I suppose that the same applies to other
programmers.  (Note that I am not speaking of checks used during
the debugging phase; there one needs all the help one can get.
:-)

In fact, the only place that I recommend parameter validation of
any kind is in functions that are callable from the outside world
(entry points to libraries, subsystem entry points, etc.) And
even there, I only recommend this when the cost of a failure (in
the final product) is fairly high.

:                I would say that it pays to perform parameter validation,
: not merely while debugging an application, but at all times

Such blanket assertions are almost always wrong; and in this case
is certainly wrong, for the reasons I gave above.  Could we
please refrain from stating relatives as if they were absolutes?
(Remember the flames about "is volatile necessary"?  Using
absolutes this way guarantees that kind of flame.)

:                                                             and that the
: specifications should include, as a matter of course, the actions to be
: taken when parameters are not valid.

This *is* a good idea when robustness is important.

:                                       My view is that one should never
: assume, as a matter of course, that software is correct.

And my view is that one should balance the cost of software
failure against the cost of making it less likely to fail.

---
Bill

You can still reach me at proxftl!bill
But I'd rather you send to proxftl!twwells!bill