1) The documentation doesn't show what file needs to be included; I think it's "mulle_allocator/mulle_allocator.h"<p>2) It can be convenient, in mulle_allocator.h, to have a define: #define malloc() mulle_malloc(). That way you don't actually need to dig through the code and replace anything.<p>3) If you're doing #defines, you can do something like this: #define malloc(a) mulle_malloc(a, __LINE__, __FILE__) which will let you keep track of the line and file where the memory was allocated.<p>4) If you're on Linux (which often C programmers are not) then mtrace() works really nicely for this.<p>5) It's always better to have more options for memory debugging, so good job!
This seems to be a malloc()/free() wrapper that keeps track of malloc()ed/realloc()ed/free()d pointers. I see that it's been submitted by the author, so one hopefully-helpful comment: it would be really helpful to highlight why one would use this instead of one of the well-established alternatives (Boehm GC, valgrind, ASan).<p>The "run after every test case" example actually gives a fairly good reason, but note that realistic code bases probably have a few caches, freelist-optimizations or other exceptions to "deallocate all memory after every test".
How do you redirect strdup() et al to your malloc? What's wrong with malloc hooks?<p><a href="http://www.gnu.org/software/libc/manual/html_node/Hooks-for-Malloc.html" rel="nofollow">http://www.gnu.org/software/libc/manual/html_node/Hooks-for-...</a>
We use something similar to this with object creation/deletion too. We set up a macro called watchallocation and watchdelete that keeps track of when objects get new'ed and deleted so we can track memory leaks. In release mode they just vanish. Quite helpfull