Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!usfvax2!jc3b21!crash
From: crash@jc3b21.UUCP (Frank J. Edwards)
Newsgroups: comp.sys.amiga.tech
Subject: Re: memalign (can it be simulated?)
Message-ID: <567@jc3b21.UUCP>
Date: 8 Feb 89 18:57:06 GMT
References: <804@sas.UUCP>
Organization: St. Petersburg Jr. College, FL
Lines: 48

In article <1989Feb1.001209.27677@ziebmef.uucp> cks@ziebmef.UUCP (Chris Siebenmann) writes:
>>In article <25616@sgi.SGI.COM> scotth@harlie.SGI.COM (Scott Henry) writes:
>> 
>> 	free(p)
>>	... operations not involving memory allocation ...
>>	q = realloc(p,size)
>>	
>>will work, ...
>>Chris Siebenmann
> [some deleted...]  Too many UN*X programs rely upon this well
> defined and almost universally supported feature.  With the Lattice compiler,
> we have gon to great lengths to support this.  As you point out, it is indeed
> pretty easy to write but somewhat harder to get right as there are several
> subtle points to the interaction.  In fact, this also works:
>     while(p!= NULL)
>        {
>        free(p);
>        p = p->next;
>        }
> And is required to work for any UN*X compatible memory manager.  If you think
> about it, this is actually a useful feature (but not a practice that I would
> recommend) that can make coding easier when you are just hacking out a fast
> solution.  I don't recommend using it but did want to point out that you 
> can expect this to work on any UN*X compatible system (otherwise you may spend
> a lot of time chasing some very obscure bugs).

Ahem, ... I'm probably going to be shot for this, but:  only expect that
behaviour on a BSD-like UN*X system.  As I understand it, BSD does not
return free'd memory (as in the sbrk() system call) back to the system.
That's why the reference will still work.  (Of course, on a BSD machine
you can allocate 4MB of RAM then free 3MB while the operating system
doesn't actually make that 3MB available to other tasks...  Wonder what
database managers do about that?!)

System V machines, however, actually remove those memory pages from
the tasks allocation tables -- the memory is GONE!  At least from the
standpoint of your task, it is.  I don't know of any software written
for System V which uses this "feature".  (But then again I'm somewhat
of a hermit ;-)  This does not preclude the possibility of an srbk()
call which does not free up an entire page, however.  Say a machine
uses a page size of 4K.  That entire page belongs to the task until
an sbrk() occurs which specifies an address logically less than the
beginning of said page.

Well, I've stuck my neck out -- does anyone know differently???

Frank "Crash" Edwards
"No one knows the trouble I've seen..."