为什么不将alloca（）用作良好实践？

alloca()在的情况下，在栈而不是堆上分配内存malloc()。因此，当我从例程返回时，内存被释放。因此，实际上这解决了我释放动态分配的内存的问题。释放通过分配的内存malloc()是一个头疼的大问题，如果以某种方式错过，则会导致各种内存问题。

alloca()尽管有上述功能，为什么不鼓励使用？

答案就在man页面上（至少在Linux上）：

返回值alloca（）函数返回一个指向已分配空间开头的指针。如果分配导致堆栈溢出，则程序行为未定义。

这并不是说永远不应该使用它。我从事的OSS项目之一广泛使用它，只要您不滥用它（具有alloca巨大价值），就可以了。一旦超过“几百个字节”标记，就可以使用malloc和朋友了。您可能仍然会遇到分配失败的情况，但是至少您会发现失败的迹象，而不仅仅是崩溃。

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

在头文件中：

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

在实现文件中：

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

所以发生了什么事，内联了编译器 DoSomething函数，所有堆栈分配都发生在Process()函数内部，从而炸毁了堆栈。在我的辩护中（我不是发现问题的人；当我无法解决问题时，我不得不哭泣向一位高级开发人员求助），它不是直截了当的alloca，它是ATL字符串转换之一宏。

因此，教训是-不要alloca在您认为可能内联的函数中使用。

旧问题，但没有人提到应将其替换为可变长度数组。

char arr[size];

代替

char *arr=alloca(size);

它在标准C99中，并且作为许多编译器的编译器扩展存在。

如果您不能使用标准局部变量，则alloca（）非常有用，因为它的大小需要在运行时确定，并且您可以 绝对保证从alloca（）获得的指针将永远不会在此函数返回后使用。

如果您可以相当安全

• 不要返回指针或包含指针的任何东西。
• 不要将指针存储在堆上分配的任何结构中
• 不要让任何其他线程使用指针

真正的危险来自某人稍后某个时候违反这些条件的机会。考虑到这一点，将缓冲区传递给将文本格式化为它们的函数非常好:)

如本新闻组中所述，有一些原因导致使用alloca困难和危险：

• 并非所有编译器都支持alloca。
• 一些编译器以alloca不同的方式解释预期的行为，因此即使支持它的编译器之间也无法保证可移植性。
• 一些实现是错误的。

一个问题是，尽管它得到了广泛的支持，但它不是标准的。在其他条件相同的情况下，我将始终使用标准函数而不是通用的编译器扩展。

仍然不鼓励使用alloca，为什么呢？

我不认为这样的共识。很多强大的职业选手；一些缺点：

• C99提供可变长度的数组，通常会优先使用该符号，因为该符号与固定长度的数组和直观的整体效果更一致
• 许多系统可用于堆栈的整体内存/地址空间少于可用于堆栈的内存/地址空间，这使程序更容易受到内存耗尽（通过堆栈溢出）的影响：这可能被视为好事或坏事-一个堆栈不能像堆一样自动增长的原因是为了防止失控程序对整个计算机产生不利影响
• 在更局部的范围（例如a while或for循环）或多个范围中使用时，内存会在每次迭代/作用域中累积，并且直到函数退出才会释放：这与控制结构范围内定义的普通变量形成对比（例如for {int i = 0; i < 2; ++i) { X }会累积allocaX处请求的-ed内存，但固定大小的数组的内存将在每次迭代中回收。
• 现代编译器通常不会inline调用该函数alloca，但是如果您强制使用它们，alloca则将在调用者的上下文中发生（即，直到调用者返回之前，堆栈才会被释放）
• 很久以前alloca从非便携式功能/ hack过渡到标准化扩展，但可能仍存在一些负面印象
• 生命周期受功能范围的约束，这可能会或可能不适合于程序员malloc的显式控制
• 必须使用malloc鼓励考虑重新分配-如果通过包装器功能（例如WonderfulObject_DestructorFree(ptr)）进行管理，则该功能为实现清除操作（如关闭文件描述符，释放内部指针或进行一些日志记录）提供了一个要点，而无需对客户端进行显式更改代码：有时候采用一致是一个很好的模型
  • 在这种伪OO风格的编程中，很自然需要这样的东西WonderfulObject* p = WonderfulObject_AllocConstructor();-当“构造函数”是一个返回malloc-ed内存的函数时，这是可能的（因为在函数返回要存储在中的值之后，内存仍被分配p），但不是如果“构造函数”使用alloca
    • 宏版本WonderfulObject_AllocConstructor可以实现此目的，但“宏是邪恶的”，因为它们可能彼此冲突且与非宏代码冲突，并导致意外替换和随之而来的难以诊断的问题
  • freeValGrind，Purify等可以检测到丢失的操作，但始终无法始终检测到丢失的“析构函数”调用-在强制执行预期用途方面，这是非常微不足道的好处；一些alloca()实施方式（诸如GCC的）用于内联宏alloca()，这样一个存储器使用的诊断库的运行时间替换是不可能它是用于方式malloc/ realloc/ free（例如电栅栏）
• 一些实现有一些细微的问题：例如，在Linux联机帮助页中：

  在许多系统上，不能在函数调用的参数列表内使用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
    }
}

所有其他答案都是正确的。但是，如果您要分配使用的东西alloca()很小，我认为这是个好方法，比使用malloc()其他方法更快，更方便。

换句话说，它alloca( 0x00ffffff )是危险的，并且很可能导致溢出char hugeArray[ 0x00ffffff ];。谨慎而合理，您会没事的。

这个“老”问题有很多有趣的答案，甚至还有一些相对较新的答案，但我没有发现任何提及这个问题的答案。

如果使用得当，请谨慎使用alloca() （如果可能在整个应用程序范围内）一致地使用，以处理较小的可变长度分配（或C99 VLA，如果可用），与使用固定长度的超大局部数组的等效实现相比，它可能导致总体堆栈增长降低。。因此，如果仔细使用它alloca()可能对您的堆栈有好处。

我找到了那个报价。...好，我把那个报价编了起来。但实际上，请考虑一下...。

@j_random_hacker在其他答案下的评论中是非常正确的：避免使用过alloca()大的本地数组来支持程序不会使程序免受堆栈溢出的影响（除非您的编译器足够老，可以内联使用的函数，alloca()在这种情况下，您应该升级，或者除非您使用alloca()内部循环，否则在这种情况下，您不应该使用alloca()内部循环）。

我曾在台式机/服务器环境和嵌入式系统上工作。许多嵌入式系统根本不使用堆（它们甚至不支持堆），原因包括人们认为动态分配的内存是有害的，这是由于应用程序存在内存泄漏的风险，一次会重新启动数年，或者更合理的理由认为动态内存是危险的，因为无法确定某个应用程序永远不会将其堆碎片化为错误的内存耗尽点。因此，嵌入式程序员几乎没有其他选择。

alloca() （或VLA）可能只是完成这项工作的合适工具。

我一次又一次地看到程序员使堆栈分配的缓冲区“大到足以应付任何可能的情况”。在深度嵌套的调用树中，重复使用该（反-）模式会导致堆栈使用过度。（想象一下，调用树深度为20层，由于不同的原因，在每个层上，该函数盲目地过度分配1024个字节的缓冲区“为了安全起见”，而通常它只会使用16个或更少的缓冲区，极少数情况下可能会使用更多。）一种替代方法是使用alloca()或VLA并仅分配函数所需的堆栈空间，以避免不必要地增加堆栈负担。希望当调用树中的一个函数需要比正常更大的分配时，调用树中的其他函数仍在使用其正常的小分配，并且与每个函数盲目地过度分配本地缓冲区的情况相比，整个应用程序堆栈的使用率要低得多。 。

但是，如果您选择使用alloca()...

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

每个人都已经指出了一个大问题，即堆栈溢出可能导致未定义的行为，但是我应该提到Windows环境具有使用结构化异常（SEH）和保护页来捕获此错误的强大机制。由于堆栈仅根据需要增长，因此这些保护页位于未分配的区域。如果分配给它们（通过溢出堆栈），则会引发异常。

您可以捕获此SEH异常，然后调用_resetstkoflw以​​重置堆栈并继续以自己的方式继续。这不是理想的方法，但是它是至少可以在出现问题时知道出问题的另一种机制。* nix可能有一些我不知道的类似东西。

我建议通过包装alloca并在内部对其进行跟踪来限制最大分配大小。如果您真的很顽固，则可以在函数顶部放置一些范围哨兵，以跟踪函数范围内的所有alloca分配，并根据项目允许的最大数量对此进行检查。

此外，除了不允许内存泄漏外，alloca不会导致内存碎片，这非常重要。如果您聪明地使用alloca，我认为它并不是坏习惯，这基本上适用于所有情况。:-)

alloca（）很好并且很有效...但是它也被深深地打断了。

• 损坏的作用域行为（函数作用域而不是块作用域）
• 与malloc不一致使用（不应释放alloca（）- ted指针，因此，您必须跟踪指针从何处指向free（），而仅跟踪malloc（）获得的指针）
• 同时使用内联时的不良行为（scope有时会转到调用方函数，具体取决于被调用方是否内联）。
• 没有堆栈边界检查
• 发生故障时发生未定义的行为（不会像malloc一样返回NULL。由于什么也不会检查堆栈边界，所以故障意味着什么……）
• 不是ansi标准

在大多数情况下，您可以使用局部变量和主要大小来替换它。如果用于大型对象，将它们放在堆上通常是一个更安全的想法。

如果确实需要C，则可以使用VLA（C ++中没有vla，太糟糕了）。在范围行为和一致性方面，它们比alloca（）更好。如我所见，VLA是一种正确的alloca（）。

当然，使用所需空间的主要部分的局部结构或数组仍然更好，如果没有这样的主要堆分配，则使用纯malloc（）可能是明智的。我看不到任何合理的用例，在这些情况下，您确实确实需要alloca（）或VLA。

原因如下：

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

并不是有人会写这段代码，而是您传递给的size参数alloca几乎可以肯定来自某种输入，这可能会恶意地将您的程序扩展到alloca类似这样的规模。毕竟，如果大小不是基于输入的，或者没有很大的可能性，为什么不只声明一个固定大小的局部本地缓冲区呢？

几乎所有使用alloca和/或C99 vlas的代码都有严重的错误，这些错误会导致崩溃（如果您很幸运）或特权泄露（如果您不太幸运）。

我认为没有人提到过这一点：在函数中使用alloca会阻止或禁用某些本可以应用在函数中的优化，因为编译器无法知道函数堆栈帧的大小。

例如，C编译器的常见优化是消除在函数中使用帧指针，而是相对于堆栈指针进行帧访问；因此，还有一个通用寄存器。但是，如果在函数内调用alloca，则部分函数无法知道sp和fp之间的差异，因此无法进行此优化。

考虑到其使用的稀有性以及其作为标准函数的不安全状态，编译器设计人员很可能会禁用可能对alloca造成麻烦的任何优化，如果要花费更多的精力才能使其与alloca一起使用。

更新： 由于可变长度局部数组已添加到C中，并且由于它们在分配程序中与alloca呈现出非常相似的代码生成问题，因此我看到“使用稀有性和不可靠状态”不适用于底层机制；但是我仍然怀疑使用alloca或VLA会损害使用它们的函数中的代码生成。我欢迎编译器设计师的任何反馈。

一个陷阱alloca是longjmp倒退的。

也就是说，如果使用保存上下文setjmp，则需要alloca一些内存，然后再保存到上下文，则longjmp可能会丢失该alloca内存。堆栈指针又回到了原来的位置，因此不再保留内存。如果您调用一个函数或执行另一个函数alloca，则会破坏原始函数alloca。

为了澄清，我在这里具体指的是一种情况，其中这种情况longjmp不会从发生功能的alloca地方返回！而是，函数使用来保存上下文setjmp；然后使用分配内存，alloca最后对该上下文进行一次longjmp。该函数的alloca内存并没有全部释放。只是自以来分配的所有内存setjmp。当然，我说的是一种观察到的行为。alloca我所知道的任何此类要求都没有记录在案。

文档中的重点通常是这样的概念：alloca内存与功能激活关联，而不与任何块关联；alloca该函数的多次调用仅会占用更多的堆栈内存，而这些内存将在函数终止时释放。不是这样；内存实际上与过程上下文相关联。使用还原上下文后longjmp，先前alloca状态也将恢复。这是因为堆栈指针寄存器本身被用于分配，并且（有必要）保存和恢复到jmp_buf。

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

我已经将其作为错误的根本原因。

一个alloca()比malloc()内核特别危险的地方-典型操作系统的内核具有固定大小的堆栈空间，其硬编码到其头文件中；它不像应用程序堆栈那样灵活。alloca()以不必要的大小进行调用可能会导致内核崩溃。某些编译器alloca()会在编译内核代码时应在某些选项下警告使用（甚至是VLA）-在这里，最好在堆中分配不受硬编码限制固定的内存。

如果您不小心写了超出分配的块alloca（例如，由于缓冲区溢出），那么您将覆盖函数的返回地址，因为该地址位于堆栈的“上方”，即在分配的块之后。

其结果有两个方面：

1. 该程序将崩溃，无法知道崩溃的原因或位置（由于帧指针被覆盖，堆栈很可能会退回到随机地址）。

2. 由于恶意用户可以制作特殊的有效负载，因此缓冲区溢出的危险要高出许多倍，有效负载会被放入堆栈中，从而最终被执行。

相反，如果您在堆上写的超出块，则“只是”得到堆损坏。该程序可能会意外终止，但会正确展开堆栈，从而减少了恶意代码执行的机会。

可悲的alloca()是，几乎很棒的tcc缺少真正出色的工具。海湾合作委员会的确有alloca()。

1. 它播下了自己毁灭的种子。以return作为析构函数。

2. 像malloc()它在失败时返回一个无效指针，它将在带有MMU的现代系统上进行段错误（并希望在没有MMU的情况下重新启动它们）。

3. 与自动变量不同，您可以在运行时指定大小。

它与递归一起很好地工作。您可以使用静态变量来实现类似于尾部递归的功能，并仅使用其他一些变量将信息传递给每次迭代。

如果推得太深，则会确保出现段故障（如果您有MMU）。

注意 malloc()由于系统内存不足时它会返回NULL（如果分配了segfault，也会返回segfault），因此不再提供任何服务。也就是说，您所能做的就是保释或只是尝试以任何方式分配它。

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

realloc()如果要复制任何现有数据，也可以用作一般情况。如果要在realloc()。之后复制或连接，则需要先检查指针以进行计算。

3.2.5.2 alloca的优势

进程仅具有有限的可用堆栈空间-远远少于可用于的内存量malloc()。

通过使用它，alloca()可以大大增加发生堆栈溢出错误的机会（如果幸运的话，或者如果不是的话，将发生莫名其妙的崩溃）。

不是很漂亮，但是如果性能确实很重要，则可以在堆栈上预分配一些空间。

如果您现在已经满足了内存块的最大大小，并且想要保留溢出检查，则可以执行以下操作：

void f()
{
    char array_on_stack[ MAX_BYTES_TO_ALLOCATE ];
    SomeType *p = (SomeType *)array;

    (...)
}

alloca功能非常强大，所有反对者都只是在传播FUD。

void foo()
{
    int x = 50000; 
    char array[x];
    char *parray = (char *)alloca(x);
}

数组和parray完全相同，风险完全相同。说一个比另一个更好是一种语法选择，而不是技术选择。

至于选择堆栈变量还是堆变量，对于长期运行的程序来说，在范围内具有生命周期的变量使用基于堆的堆栈有很多优势。您可以避免堆碎片，也可以避免使用未使用（不可用）的堆空间来增加进程空间。您不需要清理它。您可以控制进程的堆栈分配。

为什么这样不好？

实际上，不能保证alloca使用堆栈。实际上，alloca的gcc-2.95实现使用malloc本身从堆中分配内存。同样，该实现是有缺陷的，如果您在进一步使用goto的块内调用它，可能会导致内存泄漏和某些意外行为。并不是说您永远都不要使用它，但是有时alloca导致的开销要大于它释放的开销。

恕我直言，alloca被认为是不好的做法，因为每个人都担心会耗尽堆栈大小限制。

通过阅读此线程和其他链接，我学到了很多东西：

• /unix/63742/what-is-automatic-stack-expansion
• Linux 32位计算机上程序的堆栈分配限制
• ulimit -s

我主要使用alloca来使我的普通C文件在msvc和gcc上可编译，而没有任何更改，C89样式，没有#ifdef _MSC_VER等。

谢谢 ！该线程使我注册了此站点:)

我认为，alloca（）（如果有）应仅以约束方式使用。非常类似于“ goto”的使用，否则，相当多的其他有理性的人不仅对alloca（）的使用而且还存在强烈的反感。

对于嵌入式应用，已知堆栈大小并且可以通过约定和分析对分配大小进行限制，并且不能升级编译器以支持C99 +，则使用alloca（）很好，我一直在已知使用它。

如果可用，VLA可能比alloca（）有一些优点：编译器可以生成堆栈限制检查，当使用数组样式访问时，该检查将捕获超出范围的访问（我不知道是否有任何编译器这样做，但是可以完成），然后对代码进行分析即可确定数组访问表达式是否正确绑定。请注意，在某些编程环境中，例如汽车，医疗设备和航空电子设备，即使对于固定大小的阵列（自动（在堆栈上）和静态分配（全局或局部））也必须进行此分析。

在将数据和返回地址/帧指针都存储在堆栈上的体系结构上（据我所知，就是所有这些），任何由堆栈分配的变量都可能很危险，因为可以获取变量的地址，并且未经检查的输入值可能允许各种各样的恶作剧。

可移植性在嵌入式空间中不太重要，但是它是反对在精心控制的环境之外使用alloca（）的一个很好的论据。

在嵌入式空间之外，我主要在日志记录和格式化函数内部使用alloca（）来提高效率，并且在非递归词法扫描器中使用了临时结构（使用alloca（）进行分配）是在标记化和分类期间创建的，然后是持久性的函数返回之前将填充对象（通过malloc（）分配），将较小的临时结构使用alloca（）可以大大减少分配持久对象时的碎片。

这里的大多数答案在很大程度上都忽略了这一点：有一个原因为什么要使用 _alloca()可能比仅将大型对象存储在堆栈中更糟糕。

自动存储与自动存储之间的主要区别在于_alloca()后者遭受了另一个（严重）问题：分配的块不受编译器控制，因此编译器无法优化或回收它。

相比：

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

与：

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

后者的问题应该很明显。

我认为没有人提到过此问题，但是alloca还存在一些严重的安全性问题，而malloc不一定存在（尽管这些问题也存在于任何基于堆栈的数组中，无论它们是动态的还是不动态的）。由于内存是在堆栈上分配的，因此缓冲区上溢/下溢的后果要比仅使用malloc严重得多。

特别是，函数的返回地址存储在堆栈中。如果此值损坏，则可以使您的代码进入内存的任何可执行区域。编译器竭尽全力使之困难（特别是通过随机化地址布局）。但是，这显然比仅堆栈溢出更糟糕，因为如果返回值损坏，最好的情况是SEGFAULT，但是它也可能开始执行随机的内存，或者在最坏的情况下，它会开始破坏程序的安全性。 。