alloca的坑，不需要free

最近有公司在用tool扫code defect，例如malloc后，有没有判断分配的内存指针是否是NULL这些问题，如果没有判断，需要加一些error handling，例如assert。本人负责的一段历史遗留code有被扫到这个问题，有进行修改。在对函数进行review的时候，发现分配memory的函数是alloca（和calloc很相似，认为自己当时见过），使用后，并没有进行free，有检查了上下文环境的code，发现其他地方也没有free，所以判断这是一个memory leak，就手贱的修改了一下，在函数末尾添加了一个free。当时还沾沾自喜，感觉自己工作认真负责。修改后直接进行了提交，并没有验证。修改的也不多，对代码很有自信。就在今天，连续收到多笔问题NE，查看call stack，正好是添加free的地方，很是奇怪。马上Google了一下，发现alloca和calloc不一样，alloca是memory的分配是在栈上，不是在堆上，分配的memory不需要手动free，在退出函数后，会自动回收。找到原因后，将添加的free注释掉，测试后问题不再发生。

NAME
alloca - allocate memory that is automatically freed

SYNOPSIS
#include
void *alloca(size_t size);

DESCRIPTION
The alloca() function allocates size bytes of space in the stack
frame of the caller. This temporary space is automatically freed
when the function that called alloca() returns to its caller.

RETURN VALUE
The alloca() function returns a pointer to the beginning of the
allocated space. If the allocation causes stack overflow, program
behavior is undefined.

虽然问题完美的解决了，但是自己做PDCA的时候发现了多个问题。
1 当见到alloca的时候，认为自己和它很熟（其实熟的的是malloc和calloc），自信的认为和malloc和calloc一样，需要进行free，而没有深究。
问题：盲目地自信，尤其是当了多年的程序员，没有那种谨慎，喜欢用原有的经验进行推断。
2 修改后，没有进行验证。
问题：还是太相信自己的水平，尤其是仅仅增加了一行code。无论什么时候，如果对逻辑有任何修改，还是必须进行验证的，这基本是check in code的最后一段关卡。
3 对遗留的code总是抱着鄙视的心态，尤其是不是自己写的，认为别人写的code都很差，不如自己的code。
问题：遗留code仍然还在运行，说明code的逻辑没有出问题。当对遗留code进行修改的时候，一定千千万万小心，加小心。不是迫不得已，最好不要重构。如果做了任何修改，要加倍的review和测试。
4 alloca和机器编译器相关，某些场景下，效率比malloc和free要高。但如果和跨平台相关，最好不要使用。