Out of range pointers

[Henry Spencer]

In article <34041 at XAIT.XEROX.COM> g-rh at XAIT.Xerox.COM (Richard Harter) writes:
>>... in general one must draw the line somewhere.  It's almost always
>>possible to add just one more check.  There usually has to be some sort of
>>balance with efficiency.
>
>	It is true that one always has to take into account the tradeoff
>between efficiency and error checking.  However that is not normally the
>tradeoff involved in parameter validation.  Unless the body of a function
>is very short and very fast, parameter validation execution times are a
>nominal part of the total cost of a function invocation.

Ah, but it depends on how much validation you want to do, which was my
point.  I'm passing in a pointer to a complex data structure.  Do I just
check the pointer for being NULL?  Do I confirm that the node it points
at has a magic number in the right place?  Do I inspect the rest of the
node's data for plausibility?  Do I apply the same tests to the node's
neighbors?  Do I apply a graph-tracing algorithm to verify correct
linking of the whole multi-node structure?  I've actually done all of
these things at various times.  It depends on the tradeoffs.

(My normal practice?  I almost always check for NULL, and usually have
magic-number code controlled by #ifdef DEBUG.  And any time my code
vitally depends on some non-obvious property I'll usually throw in an
assert(), partly to document the fact and partly as an error-catcher.
The other things are responses to unusual situations.)
-- 
The meek can have the Earth;    |    Henry Spencer at U of Toronto Zoology
the rest of us have other plans.|uunet!attcan!utzoo!henry henry at zoo.toronto.edu