进程只有有限的堆栈空间可用——远远小于malloc()可用的内存量。

通过使用alloca()，您将极大地增加获得Stack Overflow错误的机会(如果幸运的话，或者如果运气不好，则会出现莫名其妙的崩溃)。

答案就在手册页中(至少在Linux上):

返回值 函数的作用是:返回一个指向对象开头的指针 分配空间。如果 分配的原因 堆栈溢出，程序行为未定义。

这并不是说它永远不应该被使用。我工作的一个OSS项目广泛使用它，只要你不滥用它(分配巨大的值)，它是好的。一旦超过了“几百字节”的标记，就应该转而使用malloc和friends。您可能仍然会遇到分配失败，但至少您会得到一些失败的指示，而不是仅仅耗尽堆栈。

在我看来，alloca()在可用的情况下，应该仅以受约束的方式使用。就像“goto”的使用一样，相当多理智的人不仅对alloca()的使用非常反感，而且对它的存在也非常反感。

对于嵌入式使用，其中堆栈大小是已知的，并且可以通过对分配大小的约定和分析施加限制，并且编译器不能升级到支持C99+，使用alloca()是很好的，而且我已经知道使用它。

When available, VLAs may have some advantages over alloca(): The compiler can generate stack limit checks that will catch out-of-bounds access when array style access is used (I don't know if any compilers do this, but it can be done), and analysis of the code can determine whether the array access expressions are properly bounded. Note that, in some programming environments, such as automotive, medical equipment, and avionics, this analysis has to be done even for fixed size arrays, both automatic (on the stack) and static allocation (global or local).

在堆栈上存储数据和返回地址/帧指针的架构上(据我所知，这就是它们的全部)，任何堆栈分配变量都可能是危险的，因为变量的地址可以被取走，未检查的输入值可能会允许各种各样的恶作剧。

在嵌入式领域，可移植性不是一个太大的问题，但是它是反对在严格控制的环境之外使用alloca()的一个很好的理由。

在嵌入式空间之外，我主要在日志记录和格式化函数中使用alloca()以提高效率，并在非递归词法扫描器中使用，其中临时结构(使用alloca()在标记化和分类期间创建，然后在函数返回之前填充持久对象(通过malloc()分配)。对较小的临时结构使用alloca()可以在分配持久对象时极大地减少碎片。

进程只有有限的堆栈空间可用——远远小于malloc()可用的内存量。

通过使用alloca()，您将极大地增加获得Stack Overflow错误的机会(如果幸运的话，或者如果运气不好，则会出现莫名其妙的崩溃)。

实际上，alloca并不保证使用堆栈。 事实上，gcc-2.95的alloca实现使用malloc本身从堆中分配内存。此外，这个实现是有bug的，它可能会导致内存泄漏和一些意想不到的行为，如果你在一个块内调用它进一步使用goto。并不是说您永远都不应该使用它，但有时alloca会导致比它从me中释放更多的开销。

原因如下:

char x;
char *y=malloc(1);
char *z=alloca(&x-y);
*z = 1;

并不是说任何人都可以编写这段代码，但是您传递给alloca的size参数几乎肯定来自某种输入，它可能恶意地目的是让您的程序分配一个像这样巨大的值。毕竟，如果大小不是基于输入，或者不可能很大，为什么不声明一个小的、固定大小的本地缓冲区呢?

几乎所有使用alloca和/或C99 vlas的代码都有严重的错误，这些错误会导致崩溃(如果你幸运的话)或特权损害(如果你不那么幸运的话)。