> 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-).





cgd