Alloca()在堆栈上分配内存，而不是像malloc()那样在堆上分配内存。因此，当我从例程返回时，内存被释放。这实际上解决了动态分配内存的问题。通过malloc()释放分配的内存是一个非常令人头痛的问题，如果以某种方式错过释放会导致各种内存问题。
尽管有上述特性，为什么不鼓励使用alloca() ?
当前回答
实际上，alloca并不保证使用堆栈。 事实上，gcc-2.95的alloca实现使用malloc本身从堆中分配内存。此外，这个实现是有bug的，它可能会导致内存泄漏和一些意想不到的行为，如果你在一个块内调用它进一步使用goto。并不是说您永远都不应该使用它，但有时alloca会导致比它从me中释放更多的开销。
其他回答
在我看来，分配和变长数组的最大风险是，如果分配的大小出乎意料地大，它可能会以非常危险的方式失败。
堆栈上的分配通常没有检入用户代码。
现代操作系统通常会在*下面放置一个保护页面，以检测堆栈溢出。当堆栈溢出时，内核可能会扩展堆栈或杀死进程。Linux在2017年将这个保护区域扩展到比页面大得多，但它的大小仍然是有限的。
因此，作为一条规则，在使用之前的分配之前，最好避免在堆栈上分配超过一个页面。使用分配或可变长度数组，很容易让攻击者在堆栈上进行任意大小分配，从而跳过任何保护页并访问任意内存。
*在当今最广泛的系统中，堆栈向下增长。
我遇到的最令人难忘的错误之一是与一个使用alloca的内联函数有关。它在程序执行的随机点表现为堆栈溢出(因为它在堆栈上分配)。
在头文件中:
void DoSomething() {
wchar_t* pStr = alloca(100);
//......
}
在实现文件中:
void Process() {
for (i = 0; i < 1000000; i++) {
DoSomething();
}
}
因此，发生的事情是编译器内联DoSomething函数，所有的堆栈分配都发生在Process()函数内部，从而使堆栈膨胀。在我的辩护中(我不是发现这个问题的人;当我无法修复它时，我不得不去和一个高级开发人员哭)，它不是直接的分配，它是ATL字符串转换宏之一。
所以教训是-不要在你认为可能内联的函数中使用alloca。
实际上，alloca并不保证使用堆栈。 事实上，gcc-2.95的alloca实现使用malloc本身从堆中分配内存。此外，这个实现是有bug的，它可能会导致内存泄漏和一些意想不到的行为，如果你在一个块内调用它进一步使用goto。并不是说您永远都不应该使用它，但有时alloca会导致比它从me中释放更多的开销。
进程只有有限的堆栈空间可用——远远小于malloc()可用的内存量。
通过使用alloca()，您将极大地增加获得Stack Overflow错误的机会(如果幸运的话，或者如果运气不好，则会出现莫名其妙的崩溃)。
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.
