Out-of-bounds pointers

Scott Amspoker scott at bbxsda.UUCP
Tue Oct 17 01:16:14 AEST 1989


In article <MEISSNER.89Oct14124500 at tiktok.rtp.dg.com> meissner at dg-rtp.dg.com (Michael Meissner) writes:
>In article <240 at bbxsda.UUCP> scott at bbxsda.UUCP (Scott Amspoker) writes:
>
>>  Since free() is probably the only possible way for a *valid* pointer to
>>  suddenly become *invalid* there are some interesting possibilities.
>
>Another possible way for a *valid* pointer to suddenly become
>*invalid* is if the pointer points to automatic storage and you exit
>the function creating the storage with either a return or a longjmp.

I've read several of these comments since I've made that posting.  I
decided it really wasn't worth debating but it has happened too many
times.

I was refering to the possibility that free() could be returning the
freed memory back to the system with said block of memory being removed
from the process's memory map.  Attempting to dereference a pointer
to this block of memory would result in an actual trap and code dump.

While I fully agree that a pointer to "expired" stack data is to
be considered "invalid" I am not aware of any implementation that
actually removes stack memory from the memory map upon exit from
a procedure.  That would probably slow things down considerably.
Dereferencing such a pointer would be meaningless but would probably
not cause a trap (although such a program is certainly headed for a
trap :-)

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



More information about the Comp.std.c mailing list