It's a clever idea to keep track of the chunks in your own version of malloc(), like some others have proposed own flavors of allocators for other purposes - e.g. with sentinels at the beginning and end of buffers to detect overruns; but I'm not convinced it solves all cases of leaks.
The OP essentially models within the C program what the operating system/C runtime already does for the C program - that's why we don't _need_ to call free() if we don't want to, we can just leave main or call exit() and everything will be nicely cleaned up by the OS without taking extra measures (the ISO C standard and POSIX guarantee that).
> Even if no other references to the pointer exist in the program, the pointer has not leaked.
IMHO, this is a misunderstanding. I would still call this a memory leak, because the ordinary code (the actual code that requested the particular block) lost control of it. Furthermore, how do you realize whether a particular block in the list of allocated chunks can be freed or not?
(And once you hypothetically added such a detection function, you're well on your way to implement what is called a mark-and-sweep garbage collector.)
