Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!uunet!yale!bunker!garys
From: garys@bunker.UUCP (Gary M. Samuelson)
Newsgroups: comp.lang.c
Subject: Re: effect of free()
Message-ID: <7335@bunker.UUCP>
Date: 8 Sep 89 15:46:19 GMT
References: <319@cubmol.BIO.COLUMBIA.EDU> <3756@buengc.BU.EDU> <1989Aug17.005548.745@twwells.com> <16022@vail.ICO.ISC.COM> <248@seti.inria.fr>
Reply-To: garys@bunker.UUCP (Gary M. Samuelson)
Organization: ISC-Bunker Ramo, an Olivetti Company, Shelton, Ct
Lines: 23

In article <248@seti.inria.fr> jourdan@minos.inria.fr (Martin Jourdan) writes:
>Someone else already pointed it out, but let me
>make it clear again.  Imagine a segmented memory architecture with
>protections, and imagine that the call to "free" above frees the last
>used block in the segment and that "free" is clever enough to
>determine it and decides to release the segment to the OS, thus making
>the whole segment invalid (this is perfectly conceivable, and not
>forbidden by any ``standard''; actually I'd love to see some
>programs/processes decrease their memory size when they no longer use
>it).  Then merely loading the value of "ptr" in a register to test it
>against 0 will cause a invalid-address trap.

I find this very hard to believe.  Are you being hypothetical, or
is there a machine that really does this?  I can't think of any
justification for causing an invalid-address trap when some value
is put into a register.  The trap should only occur when an attempt
is made to actually use the invalid address.  Suppose I want to
prevent invalid address traps by examining the pointer -- how could
I determine if a pointer contained a valid address, if the trap
occurs as soon as I try to look at the pointer (never mind what it
points to)??

Gary Samuelson