(Alloc and afree are introduced as examples in K&R, they are not part of C or of the standard library. Just before the bit you quoted:
Quote:
Let us illustrate by writing a rudimentary storage allocator. There are two routines.
)
A memory allocator is solving a very general problem, and won't have ideal behaviour in all cases. For that reason, you often find specialised allocators for more specific purposes: for small short-lived allocations, for large allocations, for allocations of a given size, for LIFO allocations. It's not uncommon for an application to allocate one or more large pieces of memory and then perform its own allocation tactics within - the application has a chance of knowing what kinds of allocation patterns will occur.
In fact the same sort of thing is true in storage: there are different filesystems which suit different workloads, and sometimes an application will use a large flat file and allocate space within it. Or even work directly with a partition.
Edit: It's probably the case, Garth, that if you're writing the applications which are using your allocator, you'll have some idea of what kinds of allocations you'll need, and your allocator will be good for the purpose. But it's also likely that you haven't anticipated all the patterns of allocation which applications can make, and so your idea wouldn't be as good an allocator as one written by experts and which has stood the test of time.
Edit: To summarise, there's no single best answer, and won't ever be, because memory allocation is about predicting the future, which is known to be hard. You'll find many allocators being proposed and compared - for example a few at
https://locklessinc.com/benchmarks_allocator.shtmlEdit: There's certainly an advantage of an allocator which is good enough for your own purposes and as simple as it can be for those purposes.