Subject: Re: sbrk() semantics ....
To: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
From: Chris G Demetriou <Chris_G_Demetriou@LAGAVULIN.PDL.CS.CMU.EDU>
Date: 03/13/1995 08:04:39
> Speaking as someone who's written software that uses sbrk(), the first
> two reasons that come to mind are (a) to allocate large chunks of
> memory that will never be freed, without the space wastage malloc()
> often produces, and (b) for anything that needs a memory allocator more
> sophisticated than malloc().
that's what mmap(), or, on mach systems, vm_allocate() is for.
> But IMO _some_ mechanism should be exported
> for user-land to get memory without the time and space overheads
> imposed by malloc(). And indeed, on any system where malloc() is
> itself user-land code, there must be such a mechanism...
malloc has to be implemented, _somehow_. assuming it's not in the
kernel, that method can be used (assuming it's not sbrk(), in which
case the argument is moot... 8-).