Out of range pointers

[T. William Wells]

In article <33789 at XAIT.XEROX.COM> g-rh at 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