为什么Windows平台setjmp()需要2个参数而Linux平台仅需1个参数？

核心原因 #

setjmp的参数数量差异是两个平台C运行时（CRT）的私有扩展实现和标准接口封装逻辑不同导致的。ISO C标准仅规定setjmp接受1个jmp_buf类型的上下文指针参数，平台可以基于自身需求扩展底层实现，只要对外暴露符合标准的调用接口即可。

各平台实现差异 #

Windows MSVC CRT实现 #

• 你的编译日志存在C4013: 'setjmp' undefined警告，说明代码没有引入标准头文件<setjmp.h>，编译器没有找到标准setjmp的宏定义，直接调用了MSVC底层私有的双参数实现__intrinsic_setjmp。
  该实现的第二个参数是栈异常展开控制位：传0/NULL时，后续调用longjmp不会执行SEH异常栈展开逻辑，适合动态生成代码、自定义栈结构等标准异常机制无法覆盖的场景（比如示例中的QEMU场景，栈展开会直接崩溃）；传非0值时会绑定当前栈帧的SEH信息，longjmp时会正常执行栈上的__finally清理逻辑。
• 如果你引入了<setjmp.h>，MSVC也会提供符合C标准的单参数setjmp宏，自动封装第二个参数的默认值，上层调用不需要手动传参。

Linux glibc实现 #

• glibc严格遵循POSIX和ISO C标准，<setjmp.h>中直接将setjmp定义为仅接受1个参数的宏，没有额外的扩展参数，所以传入2个参数会直接触发预编译阶段的宏参数数量不匹配错误。
• glibc的setjmp默认已经内置了信号掩码保存、栈上下文存储的逻辑，不需要额外参数控制行为。

跨平台适配方案 #

你找到的QEMU适配代码是行业通用的标准方案：

#if defined(_WIN64)
/* On w64, setjmp is implemented by _setjmp which needs a second parameter.
 * If this parameter is NULL, longjump does no stack unwinding.
 * That is what we need for QEMU. Passing the value of register rsp (default)
 * lets longjmp try a stack unwinding which will crash with generated code. */
# undef setjmp
# define setjmp(env) _setjmp(env, NULL)
#endif

通过条件编译将Windows下的单参数标准调用转换为底层双参数实现，上层业务代码可以统一使用setjmp(env)的标准写法，不需要区分平台。

注意：不要自定义JUMP_BUFFER类的上下文结构，不同平台的jmp_buf布局差异极大，直接使用标准头文件<setjmp.h>中定义的jmp_buf类型即可保证兼容性。

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