alloca()与setjmp配合的作用及栈行为相关问题探究

问题1：alloca为何能让routineB的栈保持“有效”？它是危险函数吗？ #

咱们先拆解alloca的工作逻辑：它和malloc完全不一样，不是从堆上分配内存，而是直接在当前函数的栈帧上扩展空间——说白了就是把栈指针直接挪一段距离，把当前函数的栈帧变大。这块内存不需要手动释放，函数返回时栈帧销毁，内存自动回收。

那为什么加了alloca(2048)之后，routineB的局部变量r看起来能正常保留？其实这是钻了栈布局的空子，本质是未定义行为：
当routineA执行alloca(2048)时，栈指针向下（假设栈是向下生长的）挪了2048字节，相当于给routineA的栈帧“垫了一块大缓冲区”。之后调用routineB，routineB的栈帧是建在这块缓冲区的上方。当routineB通过longjmp跳回routineA时，routineA后续的操作（比如r++、printf）都在自己的栈帧（包括那块2048字节的缓冲区）里折腾，不会碰routineB的栈帧内存。等routineA再longjmp回routineB时，routineB的栈内存还没被覆盖，所以r的值看起来是对的。

但alloca确实是出了名的“危险函数”，原因有这些：

• 不可移植：它的行为完全依赖编译器和平台的栈实现，换个编译器或者系统就可能出问题；
• 栈溢出风险：如果分配的内存太大，直接就把栈撑爆了，而且没有可靠的方式检测溢出；
• 使用场景受限：比如在函数参数里用alloca，会打乱栈布局，直接触发未定义行为；
• 无法手动管理：内存只能在函数返回时释放，中间没法主动回收。

至于是否应该这么用？绝对不建议。这种用法完全依赖栈的具体布局，属于标准里明确的未定义行为，今天能跑通，换个优化级别、换个编译器就可能崩溃或者输出乱码。真要实现协程，有更可靠的方式，比如POSIX的ucontext系列函数，或者专门的协程库，别拿alloca这种野路子碰运气。

问题2：移除alloca后不同优化级别输出不同，是未定义行为吗？ #

没错，这就是标准定义的未定义行为。咱们捋清楚逻辑：当routineB通过longjmp跳回routineA时，routineB的栈帧已经被销毁了——栈指针回到了routineA的位置，routineB的局部变量r所在的内存已经不属于它了。之后routineA的操作（比如修改自己的r、调用printf）很可能会覆盖这块内存。等routineA再longjmp回routineB时，访问r就是在读已经被篡改的内存，结果自然乱七八糟。

为什么不同优化级别输出不一样？

• -O0（无优化）：编译器会把变量r老老实实存在栈上，routineA的操作覆盖了routineB的r所在的栈内存，就出现了随机的垃圾值（比如你看到的6356584）；
• -O2（高优化）：编译器会把r优化到寄存器里，而longjmp会打乱寄存器的状态——优化器默认程序不会用longjmp跳回已经退出的函数栈帧，所以做了不符合实际的优化，导致r的值变成0，甚至routineA的r也出现了错误（比如A3的r变成1而不是2）。

要让代码行为一致？既然是未定义行为，正确的做法是彻底避免这种栈帧重叠的访问。给每个协程分配独立的栈空间才是正道——比如用malloc一块内存作为协程栈，配合ucontext或者其他协程API来管理上下文，这样每个协程的栈是独立的，不会互相覆盖，行为也就稳定了。

内容的提问来源于stack exchange，提问作者JustWe