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

可悲的是，真正强大的alloca()在几乎强大的tcc中缺失了。Gcc确实有alloca()。

它播下了毁灭自己的种子。用return作为析构函数。 像malloc()一样，它在失败时返回一个无效的指针，这将在有MMU的现代系统上分段故障(希望重新启动那些没有MMU的系统)。 与自动变量不同，您可以在运行时指定大小。

它可以很好地用于递归。您可以使用静态变量来实现与尾递归类似的功能，并使用其他几个变量向每次迭代传递信息。

如果你推得太深，你肯定会出现段错误(如果你有一个MMU)。

注意，malloc()没有提供更多，因为当系统内存不足时，它会返回NULL(如果分配了NULL，也会出现段错误)。也就是说，你所能做的就是保释或试图以任何方式转让它。

要使用malloc()，我使用全局变量并将其赋值为NULL。如果指针不是NULL，我在使用malloc()之前释放它。

如果想复制任何现有数据，也可以使用realloc()作为一般情况。在使用realloc()之前，您需要检查指针，以确定是否要在realloc()之后复制或连接。

3.2.5.2 alloca的优点

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

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

原因如下:

char x;
char *y=malloc(1);
char *z=alloca(&x-y);
*z = 1;

并不是说任何人都可以编写这段代码，但是您传递给alloca的size参数几乎肯定来自某种输入，它可能恶意地目的是让您的程序分配一个像这样巨大的值。毕竟，如果大小不是基于输入，或者不可能很大，为什么不声明一个小的、固定大小的本地缓冲区呢?

几乎所有使用alloca和/或C99 vlas的代码都有严重的错误，这些错误会导致崩溃(如果你幸运的话)或特权损害(如果你不那么幸运的话)。

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

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

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

仍然不鼓励使用分配，为什么?

我没有看到这样的共识。很多强大的专业人士;一些缺点:

C99 provides variable length arrays, which would often be used preferentially as the notation's more consistent with fixed-length arrays and intuitive overall many systems have less overall memory/address-space available for the stack than they do for the heap, which makes the program slightly more susceptible to memory exhaustion (through stack overflow): this may be seen as a good or a bad thing - one of the reasons the stack doesn't automatically grow the way heap does is to prevent out-of-control programs from having as much adverse impact on the entire machine when used in a more local scope (such as a while or for loop) or in several scopes, the memory accumulates per iteration/scope and is not released until the function exits: this contrasts with normal variables defined in the scope of a control structure (e.g. for {int i = 0; i < 2; ++i) { X } would accumulate alloca-ed memory requested at X, but memory for a fixed-sized array would be recycled per iteration). modern compilers typically do not inline functions that call alloca, but if you force them then the alloca will happen in the callers' context (i.e. the stack won't be released until the caller returns) a long time ago alloca transitioned from a non-portable feature/hack to a Standardised extension, but some negative perception may persist the lifetime is bound to the function scope, which may or may not suit the programmer better than malloc's explicit control having to use malloc encourages thinking about the deallocation - if that's managed through a wrapper function (e.g. WonderfulObject_DestructorFree(ptr)), then the function provides a point for implementation clean up operations (like closing file descriptors, freeing internal pointers or doing some logging) without explicit changes to client code: sometimes it's a nice model to adopt consistently in this pseudo-OO style of programming, it's natural to want something like WonderfulObject* p = WonderfulObject_AllocConstructor(); - that's possible when the "constructor" is a function returning malloc-ed memory (as the memory remains allocated after the function returns the value to be stored in p), but not if the "constructor" uses alloca a macro version of WonderfulObject_AllocConstructor could achieve this, but "macros are evil" in that they can conflict with each other and non-macro code and create unintended substitutions and consequent difficult-to-diagnose problems missing free operations can be detected by ValGrind, Purify etc. but missing "destructor" calls can't always be detected at all - one very tenuous benefit in terms of enforcement of intended usage; some alloca() implementations (such as GCC's) use an inlined macro for alloca(), so runtime substitution of a memory-usage diagnostic library isn't possible the way it is for malloc/realloc/free (e.g. electric fence) some implementations have subtle issues: for example, from the Linux manpage:

在许多系统中，alloca()不能在函数调用的参数列表中使用，因为由alloca()保留的堆栈空间将出现在堆栈中用于函数参数的空间中间。

我知道这个问题被标记为C，但作为一名c++程序员，我认为我应该使用c++来说明alloca的潜在效用:下面的代码(以及这里的ideone)创建了一个向量，跟踪不同大小的多态类型，这些类型是堆栈分配的(生命期与函数返回绑定)，而不是堆分配的。

#include <alloca.h>
#include <iostream>
#include <vector>

struct Base
{
    virtual ~Base() { }
    virtual int to_int() const = 0;
};

struct Integer : Base
{
    Integer(int n) : n_(n) { }
    int to_int() const { return n_; }
    int n_;
};

struct Double : Base
{
    Double(double n) : n_(n) { }
    int to_int() const { return -n_; }
    double n_;
};

inline Base* factory(double d) __attribute__((always_inline));

inline Base* factory(double d)
{
    if ((double)(int)d != d)
        return new (alloca(sizeof(Double))) Double(d);
    else
        return new (alloca(sizeof(Integer))) Integer(d);
}

int main()
{
    std::vector<Base*> numbers;
    numbers.push_back(factory(29.3));
    numbers.push_back(factory(29));
    numbers.push_back(factory(7.1));
    numbers.push_back(factory(2));
    numbers.push_back(factory(231.0));
    for (std::vector<Base*>::const_iterator i = numbers.begin();
         i != numbers.end(); ++i)
    {
        std::cout << *i << ' ' << (*i)->to_int() << '\n';
        (*i)->~Base();   // optionally / else Undefined Behaviour iff the
                         // program depends on side effects of destructor
    }
}