🚀 go-pugleaf

In article <MEISSNER.89Oct14124500@tiktok.rtp.dg.com> meissner@dg-rtp.dg.com (Michael Meissner) writes:
>In article <240@bbxsda.UUCP> scott@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