Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn) Newsgroups: comp.std.c Subject: Re: Out-of-bounds pointers Message-ID: <11319@smoke.BRL.MIL> Date: 17 Oct 89 05:11:18 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> scott@bbxsda.UUCP (Scott Amspoker) writes: >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 :-) Again, the question is NOT about dereferencing the pointer value, but rather about accessing the now-invalid pointer value at all. On the same general class of architectures for which it would be a problem for free()d pointers, it could easily be a problem for expired activation records (what you would probably call a "stack frame", but in a true segmented architecture an activation record is a separate system-controlled object in its own right, normally reclaimed by the system immediately upon expiration of its dynamic scope). I don't know of any C compilers for the B[56]x00 family of computers, but of there are any I would expect them to exhibit this behavior.