Path: utzoo!attcan!lsuc!ncrcan!ziebmef!cks
From: cks@ziebmef.uucp (Chris Siebenmann)
Newsgroups: comp.sys.amiga.tech
Subject: Re: memalign (can it be simulated?)
Message-ID: <1989Feb1.001209.27677@ziebmef.uucp>
Date: 1 Feb 89 05:12:05 GMT
References: <5471@bsu-cs.UUCP> <25616@sgi.SGI.COM>
Reply-To: cks@ziebmef.UUCP (Chris Siebenmann)
Organization: Ziebmef Public Access Unix, Toronto, Ontario
Lines: 33

In article <25616@sgi.SGI.COM> scotth@harlie.SGI.COM (Scott Henry) writes:
...
>It turns out that Manx has TWO malloc()s... the "normal" one that (eventually)
>calls AllocMem() each time, and one in heapmem.o which works out of (defaults
>to) 40KB chunks (this one includes a realloc()). If you don't link in
>heapmem.o you get indirect AllocMem() calls. BTW, I don't understand why
>Manx only includes a realloc() in heapmem.o.

 Unfortunately, on Unix systems, the sequence
 
 	free(p)
	... operations not involving memory allocation ...
	q = realloc(p,size)
	
will work, and worse still, some programs rely on this (it's even
documented in the manual entry for realloc() on BSD and some/all
System V systems). Manx's normal free() calls FreeMem(), making it
impossible for realloc() to later reliably recover the contents of
that memory.  The heapmem.o routines allocate memory out of a
fixed-size block that is never FreeMem()'d, and can thus guarantee
Unix realloc() semantics. 

 The good news is that few programs actually use this property of
realloc(), and that a realloc() without this property that works with
the standard malloc() is fairly easy to write. If your program does
use this property of realloc(), I urge you to rewrite it; you'll be
able to use Amiga memory much more effectively.

-- 
	"Though you may disappear, you're not forgotten here
	 And I will say to you, I will do what I can do"
Chris Siebenmann		uunet!{utgpu!moore,attcan!telly}!ziebmef!cks
cks@ziebmef.UUCP	     or	.....!utgpu!{,ontmoh!,ncrcan!brambo!}cks