C开发中，内存泄漏与频繁的空指针读写造成的程序异常退出是相当头痛的问题，习惯了图形化开发或有自动内存垃圾收集功能开发语言的环境，面对C的这些指针灵活性同时带来的困扰可有如下处理原则和应对，如有不当，敬请补充指教：）

不要为了代码的“美观”而不必要地使用动态内存分配：
许多场景下，动态内存分配并不是必须的，不要为了代码的技术角度的“美观”或并不可知的“未来”的“扩展”而加入动态的内存分配，因为你不能知道这段代 码以后的维护人员是否也能理解你的代码或也象你一样严谨，恰恰是为了扩展而预留的动态内存分配地方，在后期扩展时最容易出现内存泄漏或读写错误问题；
使用宏加预定义大小数组吧，并在所有这些数组操作时与宏定义的大小数值进行检查和Ｄｅｂｕｇ输出——目的是让你知道运行时哪些旧的宏定义数组已经满足不了需求要扩展了，只需简单更新宏定义就可以应对；

字符操作永远要当心：
Ｃ的应用场景下，字符（或uint8_t）操作是最频繁的，而这也是Ｃ应用最多的场景，永远要记得使用带n的函数，如strncpy，所有返回指针都要检查好才能继续使用，如strchr；

函数调用和传值：
尽量在最上层函数使用局部变量的方式定义值，然后使用其指针在下层调用函数间进行传递，而尽量不要在最上层定义指针之在下层调用函数里动态分配，即使非 要动态分配内存，也尽量在最外层函数分配在返回后释放，而不要分散在各个功能函数中动态分配和释放，非常容易遗漏或重复释放；

如果是 在*nix平台下，熟练使用dump core文件加gdb跟踪，可以快速定位到内存出错程序异常退出点，直接gdb>core-file core.xxxx.dumpfile之后，bt列出所有堆栈1,2,3…然后f 1[2,3,…]就可以方便debug错误点上下文（当然，gcc编译时需携带debug信息）；

使用下列的memleak工具，使 用非常简单（适用于*nix或windows下非托管c,c++等所有直接malloc,free进行内存管理的程序中^_^），即，将程序中所有 malloc,relloc和free等用该工具库中的代替，初始化时dbg_init(100)，在程序运行一段时间 后，dbg_heap_dump("")即可列出所有超过180s动态分配后还未释放的内存（包括在哪个源文件哪一行等信息），由你自己判断是不是泄漏未 释放的内存，而dbg_history_dump("");则可列出所有内存动态分配释放的历史记录，方便你跟踪某些动态内存分配后到释放的时间长度，方 便管理内存，设计和组织程序流程；

内存泄漏检测工具：Memleak.c