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

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

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

alloca的一个缺陷是longjmp将它倒带。

也就是说，如果你用setjmp保存一个上下文，然后分配一些内存，然后longjmp到上下文，你可能会失去分配的内存。堆栈指针回到原来的位置，因此内存不再保留;如果你调用一个函数或执行另一个分配，你将破坏原来的分配。

为了澄清，我在这里特别提到的是一种情况，即longjmp不返回发生分配的函数!相反，函数使用setjmp保存上下文;然后使用alloca分配内存，最后在该上下文中执行longjmp。该函数的分配内存没有全部释放;就是从setjmp开始分配的所有内存。当然，我说的是观察到的行为;据我所知，任何分配都没有这样的要求。

The focus in the documentation is usually on the concept that alloca memory is associated with a function activation, not with any block; that multiple invocations of alloca just grab more stack memory which is all released when the function terminates. Not so; the memory is actually associated with the procedure context. When the context is restored with longjmp, so is the prior alloca state. It's a consequence of the stack pointer register itself being used for allocation, and also (necessarily) saved and restored in the jmp_buf.

顺便说一句，如果这样工作的话，这提供了一种合理的机制来故意释放使用alloca分配的内存。

我曾经遇到过这种情况，这是一个bug的根本原因。

我认为没有人提到过这一点，但是alloca也有一些严重的安全问题，不一定是malloc所存在的(尽管这些问题也会出现在任何基于堆栈的数组中，无论是否是动态的)。由于内存是在堆栈上分配的，缓冲区溢出/下溢的后果比仅仅使用malloc要严重得多。

In particular, the return address for a function is stored on the stack. If this value gets corrupted, your code could be made to go to any executable region of memory. Compilers go to great lengths to make this difficult (in particular by randomizing address layout). However, this is clearly worse than just a stack overflow since the best case is a SEGFAULT if the return value is corrupted, but it could also start executing a random piece of memory or in the worst case some region of memory which compromises your program's security.

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

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

比较:

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

:

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

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

这个“老”问题有很多有趣的答案，甚至一些相对较新的答案，但我没有找到任何提到这个....

当正确和小心使用时，alloca()的一致使用 (可能是整个应用程序)来处理小的可变长度分配 (或C99 VLAs，如果可用)会导致整体堆栈降低 增长比使用超大的等效实现要快 固定长度的本地数组。因此，如果您仔细使用alloca()，它可能对您的堆栈有好处。

我在....上找到了这句话好吧，这句话是我编的。但真的，想想看....

@j_random_hacker在其他答案下面的评论中是非常正确的:避免使用alloca()来支持超大的本地数组并不能使你的程序更安全，免受堆栈溢出(除非你的编译器足够老，允许使用alloca()的函数内联，在这种情况下你应该升级，或者除非你在循环中使用alloca()，在这种情况下你应该……不要在循环内部使用alloca()。

I've worked on desktop/server environments and embedded systems. A lot of embedded systems don't use a heap at all (they don't even link in support for it), for reasons that include the perception that dynamically allocated memory is evil due to the risks of memory leaks on an application that never ever reboots for years at a time, or the more reasonable justification that dynamic memory is dangerous because it can't be known for certain that an application will never fragment its heap to the point of false memory exhaustion. So embedded programmers are left with few alternatives.

alloca()(或VLAs)可能是完成这项工作的合适工具。

I've seen time & time again where a programmer makes a stack-allocated buffer "big enough to handle any possible case". In a deeply nested call tree, repeated use of that (anti-?)pattern leads to exaggerated stack use. (Imagine a call tree 20 levels deep, where at each level for different reasons, the function blindly over-allocates a buffer of 1024 bytes "just to be safe" when generally it will only use 16 or less of them, and only in very rare cases may use more.) An alternative is to use alloca() or VLAs and allocate only as much stack space as your function needs, to avoid unnecessarily burdening the stack. Hopefully when one function in the call tree needs a larger-than-normal allocation, others in the call tree are still using their normal small allocations, and the overall application stack usage is significantly less than if every function blindly over-allocated a local buffer.

但是如果你选择使用alloca()…

根据本页上的其他答案，VLAs似乎应该是安全的(如果从循环中调用，它们不会复合堆栈分配)，但如果您正在使用alloca()，请注意不要在循环中使用它，并确保您的函数不能内联，如果它有任何可能在另一个函数的循环中调用。

在我看来，分配和变长数组的最大风险是，如果分配的大小出乎意料地大，它可能会以非常危险的方式失败。

堆栈上的分配通常没有检入用户代码。

现代操作系统通常会在*下面放置一个保护页面，以检测堆栈溢出。当堆栈溢出时，内核可能会扩展堆栈或杀死进程。Linux在2017年将这个保护区域扩展到比页面大得多，但它的大小仍然是有限的。

因此，作为一条规则，在使用之前的分配之前，最好避免在堆栈上分配超过一个页面。使用分配或可变长度数组，很容易让攻击者在堆栈上进行任意大小分配，从而跳过任何保护页并访问任意内存。

*在当今最广泛的系统中，堆栈向下增长。