Out-of-bounds pointers

[Scott Amspoker]

In article <1989Oct10.163732.3241 at jarvis.csri.toronto.edu> flaps at dgp.toronto.edu (Alan J Rosenthal) writes:
>                                                                     My
>complaint was that Mr Amspoker was making wild assertions about free() having
>historically been considered bad coding style.

Sorry if my point was not clear.  I was refering to the notion of handling
bad pointers - not the use of free().  The other thread I was refering to
*began* with a bad example of the use of free().  Then one thing led to
another.  The next thing I knew people were saying that any handling of
a bad pointer, whether it is dereferenced or not, is a *bug*.   I always
just considered it bad style.  Several readers attempted to justify
the notion by referencing various passages in the ANSI draft.  I merely used
those references in an absurd (but correct) way to show that things don't
always add up correctly.  Your indignation about my posting proves the
point I was trying to make - it *is* absurd.

Since free() is probably the only possible way for a *valid* pointer to
suddenly become *invalid* there are some interesting possibilities.
My example showed a case where a register variable contained a valid
pointer that became invalid by a call to free().  Even though the program
never uses the pointer again there is still the possibility of the pointer
being implicitly handled - if anything, by a *signal handler* which must
save and restore *all* registers.  It seems reasonable that an implementer
would have to take all of these things into account before making it
a capital offense to handle a bad pointer (i.e. core dump).  Arrangements
must be made to allow special bad pointers such as NULL and the various
values retuned by signal().

It strikes me as unlikely that such an implementation exists in this
particular manner and is probably not worth the effort.


-- 
Scott Amspoker
Basis International, Albuquerque, NM
(505) 345-5232
unmvax.cs.unm.edu!bbx!bbxsda!scott