正如在这篇新闻组帖子中提到的，有几个原因可以解释为什么使用alloca是困难和危险的:

并非所有编译器都支持alloca。 一些编译器对alloca的预期行为有不同的解释，因此即使在支持它的编译器之间也不能保证可移植性。 一些实现存在bug。

我想没有人提到过这一点:在函数中使用alloca会阻碍或禁用一些本来可以应用在函数中的优化，因为编译器无法知道函数的堆栈帧的大小。

例如，C编译器常见的优化是在函数中消除帧指针的使用，而是相对于堆栈指针进行帧访问;所以还有一种通用寄存器。但如果在函数内部调用alloca，则sp和fp之间的差异对于函数的一部分是未知的，因此无法进行此优化。

考虑到alloca的使用很少，而且它作为标准函数的不光彩地位，编译器设计人员很可能会禁用任何可能导致alloca出现问题的优化，如果要使它与alloca一起工作需要付出更多的努力的话。

更新: 由于变长局部数组已经添加到C语言中，并且由于这些向编译器提出了与alloca非常相似的代码生成问题，我看到“使用的罕见性和阴暗状态”不适用于底层机制;但是我仍然怀疑使用alloca或VLA会损害使用它们的函数中的代码生成。我欢迎来自编译器设计人员的任何反馈。

这里的大多数回答都忽略了一点:使用_alloca()可能比仅仅在堆栈中存储大对象更糟糕，这是有原因的。

自动存储和_alloca()之间的主要区别是，后者有一个额外的(严重的)问题:分配的块不受编译器控制，因此编译器无法优化或回收它。

比较:

while (condition) {
    char buffer[0x100]; // Chill.
    /* ... */
}

:

while (condition) {
    char* buffer = _alloca(0x100); // Bad!
    /* ... */
}

后者的问题应该是显而易见的。

A place where alloca() is especially dangerous than malloc() is the kernel - kernel of a typical operating system has a fixed sized stack space hard-coded into one of its header; it is not as flexible as the stack of an application. Making a call to alloca() with an unwarranted size may cause the kernel to crash. Certain compilers warn usage of alloca() (and even VLAs for that matter) under certain options that ought to be turned on while compiling a kernel code - here, it is better to allocate memory in the heap that is not fixed by a hard-coded limit.

一个问题是，它不是标准的，尽管它得到了广泛的支持。在其他条件相同的情况下，我总是使用标准函数，而不是常用的编译器扩展。

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

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

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