Alloca()在堆栈上分配内存，而不是像malloc()那样在堆上分配内存。因此，当我从例程返回时，内存被释放。这实际上解决了动态分配内存的问题。通过malloc()释放分配的内存是一个非常令人头痛的问题，如果以某种方式错过释放会导致各种内存问题。
尽管有上述特性，为什么不鼓励使用alloca() ?
当前回答
为什么没有人提到GNU文档中介绍的这个例子?
https://www.gnu.org/software/libc/manual/html_node/Advantages-of-Alloca.html
使用longjmp自动完成的非本地退出(参见非本地退出) 方法退出时释放使用alloca分配的空间 调用alloca的函数。这是使用的最重要的原因 alloca
建议阅读顺序1->2->3->1:
https://www.gnu.org/software/libc/manual/html_node/Advantages-of-Alloca.html 来自非本地出口的介绍和详细信息 Alloca例子
其他回答
实际上，alloca并不保证使用堆栈。 事实上，gcc-2.95的alloca实现使用malloc本身从堆中分配内存。此外，这个实现是有bug的，它可能会导致内存泄漏和一些意想不到的行为，如果你在一个块内调用它进一步使用goto。并不是说您永远都不应该使用它，但有时alloca会导致比它从me中释放更多的开销。
每个人都已经指出了堆栈溢出潜在的未定义行为，但我应该提到的是，Windows环境有一个很好的机制来捕捉这种情况，使用结构化异常(SEH)和保护页面。由于堆栈只在需要时增长，因此这些保护页驻留在未分配的区域。如果你对它们进行分配(通过溢出堆栈)，就会抛出一个异常。
您可以捕获这个SEH异常并调用_resetstkoflw来重置堆栈并继续您的快乐之路。这并不理想，但这是另一种机制，至少可以在事情发生时知道哪里出了问题。*nix可能有类似的东西，但我不知道。
我建议通过包装alloca并在内部跟踪它来限制您的最大分配大小。如果你真的很认真，你可以在函数的顶部设置一些作用域哨兵来跟踪函数作用域中的任何分配，并检查它与项目允许的最大数量是否一致。
此外，除了不允许内存泄漏之外，alloca也不会导致内存碎片，这是非常重要的。我不认为alloca是不好的做法，如果你明智地使用它，这基本上适用于所有事情。: -)
一个问题是，它不是标准的，尽管它得到了广泛的支持。在其他条件相同的情况下，我总是使用标准函数，而不是常用的编译器扩展。
其他答案都是正确的。但是，如果使用alloca()要分配的对象相当小，我认为这是一种比使用malloc()或其他方法更快、更方便的好技术。
换句话说，alloca(0x00ffffff)是危险的，可能会导致溢出，就像char hugeArray[0x00ffffff];是多少。小心谨慎，通情达理，你会没事的。
alloca并不比变长数组(VLA)更糟糕，但它比在堆上分配更危险。
在x86上(最常见的是在ARM上)，堆栈向下增长，这带来了一定的风险:如果你不小心写超出了用alloca分配的块(例如由于缓冲区溢出)，那么你将覆盖你的函数的返回地址，因为它位于堆栈的“上面”，即在你分配的块之后。
这样做的后果是双重的:
程序将崩溃的壮观，它将不可能告诉为什么或哪里崩溃(堆栈将最有可能unwind到一个随机地址，由于覆盖的帧指针)。 它使缓冲区溢出的危险增加了许多倍，因为恶意用户可以制作一个特殊的有效负载，将其放在堆栈上，因此最终可以执行。
相反，如果你在堆上写超过一个块，你“只是”得到堆损坏。程序可能会意外终止，但会正确地展开堆栈，从而减少恶意代码执行的机会。
