Fixed-Block Pool Allocator
The signature is trivial. The hidden tests are the allocator laws a vague spec forgets. AddressSanitizer grades the memory, not your intentions.
You are writing a fixed-block memory pool allocator in C. A pool hands out memory only from a single buffer that the caller owns, so the allocator never calls malloc or any system allocator of its own. This pattern is common in embedded systems, real-time code, and high-throughput servers where every allocation must be fast, predictable, and confined to a known region of memory.
Implement three functions. pool_init(void *buf, size_t buf_size, size_t block_size) prepares the allocator by carving the caller buffer into fixed-size blocks. pool_alloc() returns a pointer to one free block from that buffer, ready for the caller to use. pool_free(void *ptr) returns a previously allocated block to the pool. Each block must be properly aligned for general use, distinct blocks must never overlap, and the pool must be able to serve up to its full capacity of simultaneously live blocks given the buffer it was handed.
Define the exact function signatures and any return or status conventions yourself, and make the implementation behave sensibly across the full range of inputs and usage sequences a caller might throw at it.
With a 256 byte buffer and a block_size of 32, pool_init sets up the pool, and repeated pool_alloc() calls return separate, non-overlapping blocks.
- pool_init carves the buffer into fixed-size blocks.
- pool_alloc returns one 8-byte-aligned block from the buffer.
- pool_free returns a block to the pool.
- Allocate up to capacity blocks with no overlap.
The functional tests are shown, and the model usually clears them on its own. The hidden tests are the twists this kind of system is full of. They are not listed. Your spec only passes them if it already knows where this domain breaks.
185 chars