Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!bu-cs!buengc!bph
From: bph@buengc.BU.EDU (Blair P. Houghton)
Newsgroups: comp.lang.c
Subject: Re: how do you know 'free' freed?
Message-ID: <4531@buengc.BU.EDU>
Date: 14 Oct 89 01:02:25 GMT
References: <5521@hacgate.UUCP>
Reply-To: bph@buengc.bu.edu (Blair P. Houghton)
Followup-To: comp.lang.c
Organization: Boston Univ. Col. of Eng.
Lines: 39

In article <5521@hacgate.UUCP> howard@aic.dpl.scg.hac.com (Mike Howard (213)317-5690) writes:
>I've malloc'd a tree structure, and then free'd it, node by node.
>Of course, freeing it just marks it as free, and I can still walk
>through the tree after freeing it.  I'd like to confirm that it is
>in fact free.
>
>I tried malloc'ing an array after freeing the tree, but I can't 
>tell the array where to go in memory, so the tree still seems to
>be there.  There must be some way to confirm free.

Breeeeeep!

Assembler alert.

You don't have any right to expect any such thing of a computer
when you are programming in C.

Free() is, essentially, a convenience to the computer.  You're telling
it that it can clean up its act in case someone wants some more core
in the future.

"I can still walk through the tree after freeing it" is like saying
"I can still walk on the ice in april."  Yeah, you can, but you're
going to find that extra-thin patch long before you expect it, and
then you'll never say that again.

Not much else is defined about it.  Mostly it literally "frees" the
storage from the use of your program.  You can not use freed space
and legally expect it to work for you in any way.

Unfortunately, you also can't expect the system to do anything useful
with it like distill freed and unallocated space into a clean,
contiguous, allocatable block.  Luckily, they do, but you can't count
on it.

				--Blair
				  "The word 'undefined' comes up
				   unnervingly often in this business of
				   determinism and repeatability..."