detecting invalid pointers

T. William Wells bill at twwells.uucp
Sun Mar 12 02:23:12 AEST 1989


In article <3011 at nunki.usc.edu> jeenglis at nunki.usc.edu (Joe English) writes:
: Take, for example, the (you guessed it) 80x86 series in
: 'large' model, where pointers aren't normalized.  It's
: then possible for two pointers to point to the same location
: yet have different segment:offset pair values.  Most '86 compilers
: will *not* get this comparison right, since pointers are in general
: not normalized before comparisons to save time and space.

In which case, the compiler is broken. But we knew that...?

: 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.

: Range-checking and pointer validation are for programmers who are
: afraid that they might shoot themselves in the foot.  Correct code
: will avoid generating bad pointers (among other things) in the first
: place.  True, this is easier said than done -- but writing correct
: code is much more worth the effort than inserting runtime checks all
: over the place.

When you find a perfect programmer, then we can talk about correct
code and its relevance to programming. Till then, we will have to
deal with less than correct code and thus will be forced to deal with
the fact that a C program can operate in non-C ways. And so run time
checks are and will remain important, in many applications.

---
Bill
{ uunet | novavax } !twwells!bill
(BTW, I'm going to be looking for a new job sometime in the next
few months.  If you know of a good one, do send me e-mail.)



More information about the Comp.lang.c mailing list