Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!unmvax!bbx!bbxsda!scott From: scott@bbxsda.UUCP (Scott Amspoker) Newsgroups: comp.std.c Subject: Re: Out-of-bounds pointers Message-ID: <252@bbxsda.UUCP> Date: 16 Oct 89 15:16:14 GMT References: <1009@mtxinu.UUCP> <12570028@hpclwjm.HP.COM> <868@crdos1.crd.ge.COM> <217@bbxsda.UUCP> <1989Oct7.131404.656@jarvis.csri.toronto.edu> <220@bbxsda.UUCP> <1989Oct10.163732.3241@jarvis.csri.toronto.edu> <240@bbxsda.UUCP> 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