detecting invalid pointers

Ray Butterworth rbutterworth at watmath.waterloo.edu
Wed Mar 15 02:33:14 AEST 1989


In article <767 at twwells.uucp>, bill at twwells.uucp (T. William Wells) writes:
> In article <3011 at nunki.usc.edu> jeenglis at nunki.usc.edu (Joe English) writes:
> : In My Opinion, you should never *have* to check a raw pointer for
> : validity.  Any code that might possibly generate an out-of-range
> : pointer should check the subscript (or loop count, or whatever)
> : beforehand.  I wouldn't bother to validate pointers inside, say, a
> : utility routine either (other than checking for non-NULL), because it
> : takes space and time and, quite frankly, it's the caller's
> : responsibility not to pass bad pointers around.
> 
> One might want to check pointer validity to cope with program
> behavior that is outside the C model.  Such can result in an invalid
> pointer even when all other pointers are valid. Consider a pointer
> munged by a bad array reference.

There is a common case where the pointers are perfectly valid
and yet you still need to check to see if one points inside the
other even though they might actually point to completely different
objects.

Consider implementing memmov(void *to, void *from, size_t bytes).

You have to determine if the arrays starting at "to" and at "from"
overlap before you know which direction is safe for doing the copy.
i.e. if "from" points inside the "to" array, you start the copy at
the beginning of the array; but if "to" points inside the "from" array,
you start the copy at the end of the array.
(If neither condition is true it doesn't matter where you start the copy,
 and if both conditions are true you don't need to do the copy).

As has been discussed in recent postings, there isn't any obvious
simple way of performing these tests required by the pANS C library.



More information about the Comp.lang.c mailing list