Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: Memory Allocation
Message-ID: <10206@smoke.BRL.MIL>
Date: 4 May 89 13:36:46 GMT
References: <10946@bloom-beacon.MIT.EDU> <12546@ut-emx.UUCP> <29978@apple.Apple.COM> <17252@mimsy.UUCP> <1989May3.201118.10221@utzoo.uucp> <10202@smoke.BRL.MIL> <461@chem.ucsd.EDU>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 13

In article <461@chem.ucsd.EDU> tps@chem.ucsd.edu (Tom Stockfisch) writes:
>You waste up to a factor of 4 with a power-of-2 implementation,
>not including fragmentation.

The hypothetical application gloms onto a sufficiently large chunk of
memory and doles it out itself, using whatever suballocation scheme
seems appropriate for the application.  If you mean that
	void *my_heap = malloc( 1024 * 1024 * 16 );
may over-extend the program data break by up to 16Mbytes due to using
a "buddy system" scheme, I see a factor of two (not four) here, but the
problem lies with whoever provided an allocator with such horrible
properties in the C library.  In such a case, if one knows that sbrk()
is available, it should probably be used here instead of malloc().