Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!pyrdc!eliot!reidc
From: reidc@eliot.UUCP (Reid Carson/Development)
Newsgroups: comp.sys.amiga
Subject: Re: Dynamic Memory Allocation
Summary: Freed memory unsafe
Message-ID: <513@eliot.UUCP>
Date: 20 Feb 90 20:54:35 GMT
References: <2061540@mtsg.ubc.ca> <1569@sas.UUCP>
Organization: Unitech Software, Inc., Reston, VA
Lines: 29

In article <1569@sas.UUCP>, walker@sas.UUCP (Doug Walker) writes:
> In article <2061540@mtsg.ubc.ca> Kim_Sletten@MTSG.UBC.CA writes:
> >the free'd memory does not show up as being available until the
> >program terminates. Am I missing something? 
> 
> The UNIX free() function is required to work in the following situation:
> 
> for(s=head; s != NULL; s=s->next) free(s);

  I believe this is not in fact correct.  It is not portable to assume that
a pointer to freed memory can still be dereferenced, even immediately after
the call to free().  It works on many systems, yes, but not all.  This was
hashed out in comp.lang.c and/or comp.std.c a couple of months ago.  In fact,
it was even disputed whether it was proper to do comparisons with a pointer
x after doing free(x).

> This means that free() is required to 'hold on' to the most recently
> freed memory chunk until the next call to free(), or until the program
> exits.

  Free() is not required to hold on to the memory, it's just that the brk()
and sbrk() calls on UNIX systems will increase your break point, but not
decrease it.  I don't recall if this is mandated by the SVID, but it's so
much easier than trying to deal with the problems of returning an arbitrary
chunk of memory to the OS that I would be surprised if any vendor had done
otherwise.  Evidently the Amiga OS has been implemented the same way.
-- 
Reid W. Carson (uunet!pyrdc!eliot!reidc)  -  Unitech Software, Inc.
What I tell you three times is true.