<div dir="ltr">I'm writing a small C library, that I want to open source.<div><br></div><div>I want them to be usable for embedded environment, where memory allocation must be controlled.</div><div><br></div><div>Hence, I abstracted away calls to malloc/realloc, and replaced them with</div><div><br></div><div>struct mem_pool {</div><div>    void *(*allloc)(void *mem_pool, void *prev_ptr, int size);</div><div>};</div><div><br></div><div>User would implement</div><div><br></div><div>struct my_mem_pool {</div><div>    struct mem_pool pool;</div><div>    ...</div><div>};</div><div><br></div><div>struct my_mem_pool pool = { { my_alloc_func }, ...);</div><div><br></div><div>I've had to design question I'm interested with:</div><div><br></div><div>1) Should I support both malloc and realloc?</div><div><br></div><div>I think the performance benefits of supporting malloc instead of realloc(NULL) are negligible, and not worth complicating the interface.</div><div><br></div><div>2) Should the memory pool be allowed to fail?</div><div><br></div><div>In typical Linux system, where memory overcommit is allowed, checking malloc return value provides little benefit. But is it the same for embedded system?</div><div><br></div><div>My feeling is, embedded system should predict the memory usage for each input size, and avoid processing input which is too large.</div><div><br></div><div>For example, stack overflow error can never be handled, and one is expected to calculate the longest stack length for any input and make sure he wouldn't overflow.</div><div><br></div><div>So I think it's still reasonable never to report allocation failure, and to expect the memory allocator to raise the relevant abort/panic/exception in such a case.</div><div><br></div><div>But I'll be happy to hear other considerations I missed.</div><div><br></div><div>Thanks,</div></div>