既然是 C 语言, 其实没什么在意的点的话可以直接使用下面这个 Garbage Collector
http://www.hboehm.info/gc/
这个 GC 很有名, 被很多专案使用, 像是 Idris backend 就直接仰赖它, 因为方便
如果对 GC 的要求不是很多, 其实非常方便而且用起来很简单
example 就非常简单, 改成 GC_MALLOC 就对了
http://www.hboehm.info/gc/simple_example.html
它是 conservative garbage collector, 所以即使某些值(非指标)被误当成
内存位置导致无法回收, 只要这种状况不多就好 (通常是很少)
※ 引述《Hazukashiine (耻ずかしい ね...(>///<))》之铭言：
: 许多教程式的教授或是工程师会认为一个好的程式中 free() 与 *alloc() 必须成对。
: 通常执行 free() 并不会把 memory 还给 operating system，
: 反而是告诉程式，下一次 *alloc() 的时候，可以用一下之前 free() 过的空间。
: 这种设计并不坏，主要是为了节省 system call 的时间消耗。
: 虽然心中觉得成对会比较严谨一点，不过在实作的时候确实会容易造成问题。
: 问题一：
: 前一个人 free() 掉之后，并没有把指标设成 NULL，然后还在 code 中到处流串，
: 只要一不小心，*** glibc detected *** double free or corruption 就会死给你看，
: 这种 bug 最恶心了，尤其在其他 code 不是你写的时候。
: 问题二：
: 当一个函数的回传值是一个指向空间的指标的时候，
: 而且这个函数会将这个指标送给超过一个的函数的话，
: 只要其中一个函数 free() 掉之后，其他的函数也会跟着遭殃，
: 通常会送个 Segmentation fault (core dumped) 当作圣诞节礼物。
: 程式在结束的时候，大部分的作业系统都会回收内存，
: 所以，若在程式码结尾的地方 free() 掉所有申请过的空间，也是多此一举。
: 我的看法是，若该指标出现在循环中或是递回中的话，才有使用 free() 的必要，
: 其余的指标就让作业系统去回收吧，毕竟通常吃内存的怪兽都是循环或递回中的指标。
: 大家怎么看？通常都会严格遵守成对的习惯吗？