我正在使用MSVC++2012用C++编写代码，我的代码针对x86平台。我有一种情况，写一个函数（除其他外）可以在CALLING函数的堆栈上分配一些内存是有利的。我在这篇文章中并不是想辩论这样做是否明智，只是想考虑技术可行性。
我的实现计划是将我的函数写成一个裸函数，在内联汇编中使用自定义prolog代码。在序言中，我将首先确定我需要多少内存，然后将返回地址、参数和该指针沿堆栈向下移动该数量。最后，我会将堆栈指针调整这个量。如果我没有弄错的话，这将在调用函数的堆栈上创建一个区域。
有人看到那个计划有漏洞吗？
一个明显的缺点是x64不支持内联程序集，因此将来会限制您的可移植性。
另一个明显的缺点是，调用函数将期望堆栈指针位于相对于其本地的某个位置，而现在已经不是了。我相信编译器生成的代码无法应对这种情况。这种不和谐的一个简单例子是，生成的代码不知道弹出多少堆栈空间
我观察到的做您想做的事情的唯一方法是使用默认参数。你可以做例如
int f(void* p = alloca(55)) {
}
从技术上讲，由于默认参数是在调用函数中计算的，因此这将从调用函数的堆栈中分配内存。然而，正如你所观察到的，这里的核心问题是计算你需要多少空间。
几张海报都有很多优点。我将在这里避暑。
我所描述的技术将起作用，但前提是调用函数是用CDECL调用约定定义的，并且禁用堆栈帧指针的链接器开关未启用。调用函数必须是CDECL，而不是STDCALL或THISCALL，因为STDCALL和THISCALL无法正确还原调用函数的epilog中的堆栈指针，因为这些约定会从当前ESP中减去，而不是还原原始值。他们会减去错误的数量，而不考虑增加的空间，因此堆栈会被损坏。禁用堆栈帧指针的链接器开关不能处于活动状态，因为如果是，调用函数将引用参数作为ESP而不是EBP的偏移量，因此偏移量将不正确。
除了上述限制之外，使用此技术的结论是x64可移植性的损失和对性能优化的不可预测的影响。
鉴于这些限制，我选择不继续使用这种技术。