我遇到的最令人难忘的错误之一是与一个使用alloca的内联函数有关。它在程序执行的随机点表现为堆栈溢出(因为它在堆栈上分配)。

在头文件中:

void DoSomething() {
   wchar_t* pStr = alloca(100);
   //......
}

在实现文件中:

void Process() {
   for (i = 0; i < 1000000; i++) {
     DoSomething();
   }
}

因此，发生的事情是编译器内联DoSomething函数，所有的堆栈分配都发生在Process()函数内部，从而使堆栈膨胀。在我的辩护中(我不是发现这个问题的人;当我无法修复它时，我不得不去和一个高级开发人员哭)，它不是直接的分配，它是ATL字符串转换宏之一。

所以教训是-不要在你认为可能内联的函数中使用alloca。

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

当正确和小心使用时，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()，请注意不要在循环中使用它，并确保您的函数不能内联，如果它有任何可能在另一个函数的循环中调用。

alloca() is very useful if you can't use a standard local variable because its size would need to be determined at runtime and you can absolutely guarantee that the pointer you get from alloca() will NEVER be used after this function returns. You can be fairly safe if you do not return the pointer, or anything that contains it. do not store the pointer in any structure allocated on the heap do not let any other thread use the pointer The real danger comes from the chance that someone else will violate these conditions sometime later. With that in mind it's great for passing buffers to functions that format text into them :)

其他答案都是正确的。但是，如果使用alloca()要分配的对象相当小，我认为这是一种比使用malloc()或其他方法更快、更方便的好技术。

换句话说，alloca(0x00ffffff)是危险的，可能会导致溢出，就像char hugeArray[0x00ffffff];是多少。小心谨慎，通情达理，你会没事的。

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

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

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