setjmp/longjmp与打开文件状态：C标准相关规定的设计目标及实现处理方式

哈喽，针对你提到的C标准里关于longjmp的这条行为规定，我来给你拆解下它的设计目标，以及主流编译器实现通常是怎么处理的：

C标准规定：调用longjmp函数时，所有可访问对象均具有对应的值，抽象机的所有其他组件（注218）均保持调用longjmp时的状态，但存在例外——对于包含对应setjmp宏调用的函数中局部的、非volatile限定类型的自动存储期对象，若在setjmp调用与longjmp调用之间被修改，则其值是不确定的。注218：这包括但不限于浮点状态标志和打开文件的状态（重点强调）。

设计目标 #

这条规定的核心设计目标可以总结为三点：

• 平衡性能与语义可控性：setjmp/longjmp是C语言提供的底层非局部跳转机制，类似轻量级异常处理。如果强制要求所有局部变量都保留longjmp前的修改值，编译器就得禁用大量优化（比如寄存器分配、常量折叠），会严重拖慢程序效率。而volatile关键字本来就是用来告诉编译器"别优化这个变量"，把非volatile局部自动变量排除在确定值之外，既保留了编译器的优化空间，又给开发者提供了可控方式（加volatile）确保变量值一致。
• 贴合底层硬件的实际行为：大多数CPU架构中，函数局部自动变量会优先分配到寄存器（比内存访问快）。调用setjmp时会保存当前寄存器上下文到jmp_buf；后续修改非volatile局部变量本质是修改寄存器值，longjmp恢复上下文时，寄存器会还原成setjmp时的状态，导致变量值回退——但如果编译器刚好把变量分配到内存，值又会保留修改后状态。这条规定其实是如实反映硬件的不确定性，避免给编译器强加无法实现的要求。
• 明确行为边界，减少歧义：标准明确划分了"确定状态"和"不确定状态"的范围：全局变量、静态变量、volatile局部变量，以及文件状态、浮点标志这些系统组件，longjmp后状态都是确定的；只有非volatile局部自动变量可能出问题。不管是编译器开发者还是应用开发者，都有清晰规则可循，不会因行为模糊踩坑。

主流实现的处理方式 #

不同编译器的处理逻辑大体遵循标准，但有细节差异：

• GCC/Clang（Linux/macOS主流编译器）：
  • 对于包含setjmp的函数中的非volatile局部自动变量，若在setjmp和longjmp之间被修改，编译器完全遵循标准，不保证变量值——可能恢复到setjmp时的旧值（变量在寄存器），也可能保留修改后的新值（变量在内存）。开发者需给变量加volatile来确保值的一致性。
  • 全局变量、静态变量、volatile局部变量：编译器保证这些变量的值是longjmp调用时的最新值，因为它们存在内存（或volatile要求写回内存），longjmp不会修改内存内容。
  • 文件状态、浮点标志等系统组件：运行时库会保留longjmp调用时的状态，不会回滚。比如fseek移动文件指针后，longjmp后指针位置不变；浮点运算触发溢出标志，longjmp后标志也不会清除。
• MSVC（Windows主流编译器）：
  • 核心逻辑和GCC一致，但有个小细节：如果非volatile局部变量的地址被取过（用&运算符），编译器会把它分配到内存，longjmp后变量值保留修改后的状态；如果没被取地址，可能被分配到寄存器，longjmp后恢复成旧值。本质还是符合标准的"值不确定"规定，行为依赖编译器优化决策。
• 嵌入式系统编译器（比如ARM GCC、IAR）：
  • 这类编译器更贴近硬件，处理方式更直接：非volatile局部变量若在寄存器，longjmp后必然恢复到setjmp时的值；若在内存，就保留修改后的值。开发者同样需要用volatile强制变量存到内存，确保值的一致性。

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