问题标签 [alloca]

在我看来，在 C 中隐藏结构的定义通常会使代码更安全，因为您在编译器的帮助下强制要求不能直接访问结构的任何成员。

然而，它有一个缺点，结构的用户不能声明其类型的变量要放入堆栈，因为结构的大小以这种方式变得不可用（因此，用户必须求助于分配堆通过，malloc()即使它是不可取的）。

这可以（部分）通过alloca(3)所有主要 libc 实现中存在的函数来解决，即使它不符合 POSIX。

牢记这些优点和缺点，这样的设计总体上可以被认为是好的吗？

在lib.h：

在lib.c：

在example.c：

我正在使用一个不错的 GCC 扩展，它允许我们在结构中声明 VLA。现在我找到了一种通过这种方式将 VLA 传递给函数（按值）的方法。我还找到了一种返回方法，但在非常有限的情况下。

这个例子的功能代码是这样的：

上面的例子是为测试目的而设计的（特别是为了比较它编译的二进制代码）。

然而，这是非常有限的，因为返回数组的大小在函数的不同调用之间没有变化。

我怎样才能使返回的数组大小等于函数参数之一或此函数中的某个其他局部参数。

我认为alloca在这种情况下对我没有帮助，因为它分配的内存在函数退出（IRC）处立即被销毁。

我想写这样的东西：

换句话说，问号内的类型可能是什么？或者也许还有其他解决方案（但不使用malloc）？

这种函数的理论用法理论上需要另一种类型来存储返回值，因为调用者无法获得返回结构的大小（除非有办法避免这种情况？）。但乍一看它应该是这样的：

如果我们这样做：

它不起作用，因为 VM 返回类型func5将取决于它的参数或局部变量。然而，目前这一切都是理论上的，因为我们仍然无法定义这个函数。

我的stackAlloc功能如下所示：

如果我改变所以stackAlloc函数总是使用malloc而不是alloca一切正常。

我将函数更改为宏，现在它按预期工作：

regerror返回存储错误消息所需的字节数。由于我正在使用的应用程序不会在堆栈中“深入”（即没有深度嵌套的函数调用），我正在考虑使用alloca（应用程序已经将其用于其他目的）来获取错误消息的临时存储空间在堆栈（而不是堆）上。

假设错误消息（长度）有界是否安全，这样我就不会遇到堆栈溢出？

这是否会打开一个安全漏洞（通过操纵使用的消息目录）？

如果您通读 GNU libs 文档，您可以看到：

一些非 GNU 系统不支持 alloca，因此它的可移植性较差。然而，用 C 语言编写的 alloca 的较慢仿真可用于具有此缺陷的系统。

假设 VLA 也不可用， C 仿真alloca()会是什么样子？

我在 Internet 上找到的唯一alloca()C++ 替代品如下所示：

但是，很明显，这不是alloca()我们所知道和喜爱的，它不是一个函数，也不是一个宏。可以编写更接近函数调用语义的alloca()实现吗？alloca()也许作为一个宏？无论是宏还是函数，它都应该从堆栈而不是堆中分配空间。

I'm building a shared object (.so) that internally makes use of a function _alloca() (defined in malloc.h). This .so compiles smoothly. But as soon as I call a function that makes use of _alloca(), my application crashes whith a console output

So: any idea against what library I have to link during build to get this external reference resolved?

Platform is CentOS7 x64

Thanks!

alloca()通过声明一个固定大小的数组，什么时候比在堆栈上分配的内存更可取？

细节：

众所周知，alloca()是一个有争议的功能。乱用，会导致栈溢出。明智地使用，它可以通过避免堆分配从紧密循环中减少几纳秒。在这个关于为什么alloca被认为不好的问题中，几个最佳答案提倡偶尔使用alloca.

从堆栈分配的另一种方法是简单地声明一个固定大小的数组。这种策略的一个例子可以在Howard Hinnant 的 stack allocatorarena的类中找到。（该代码当然是 C++，但这个概念仍然适用于 C。）

使用alloca与固定大小数组的权衡是什么？什么时候，如果有的话，一个明显优于另一个？是否只是一个性能问题，应该在每种情况下进行经验测试（当性能是关键目标并且已经确定热点时）？固定大小的数组更加悲观——它总是分配我们愿意在堆栈上分配的数量——但尚不清楚这是好是坏。

为了尽可能清楚，这是两个函数实现的一个非常简单的示例，似乎有理由使用其中一个alloca或一个固定大小的数组：

另一个非常相似的选项alloca是 VLA。据我所知，从allocaVLA 和 VLA 获得的内存具有基本相同的行为，因此该问题也适用于 VLA。如果这种理解是错误的，只需提及它。

引用部分的第二段BUGS，来自手册页alloca(3)

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

我没有看到这将如何发生。以以下代码为例：

根据我的理解，alloca将堆栈帧向下扩展main100 个字节（通过修改堆栈指针寄存器），然后将指向该堆栈内存块的指针（连同 2int秒）在堆栈帧上传递给f. 所以分配的空间不应该在a,b或者的中间c，实际上它应该在不同的框架上（main在这种情况下是在框架上）。

那么这里有什么误解呢？

在大多数平台上，alloca归结为堆栈指针的内联调整（例如，rsp在 x64 上减去，加上一些逻辑以保持堆栈对齐）。

我正在查看gcc为 alloca 生成的代码，这很奇怪。以下面的简单示例¹为例：

这编译为以下程序集-O2：

这里有几件令人困惑的事情。我知道gcc需要将分配的大小四舍五入到 16 的倍数（以保持堆栈对齐），而通常的方法是(size + 15) & ~0xF在add rdi, 30? 那是怎么回事？

其次，我只希望结果alloca是新的rsp值，它已经很好地对齐了。相反，gcc 这样做：

这似乎是在“重新调整”rsp使用的值作为结果alloca- 但我们首先已经完成了与rsp16 字节边界对齐的工作。

那是怎么回事？

你可以在 godbolt 上玩代码。值得注意的是clang，icc至少在 x86 上做“预期的事情”。使用 VLA（如之前的评论中所建议的那样），gcc并且在产生可憎的clang同时做得很好。icc

1 在这里，对的赋值psink只是为了消耗的结果，alloca否则编译器会完全忽略它。