深入解析：C 语言中 4 种影响程序可移植性的行为

可移植性就是什么

在软件工程中，可移植性指的是软件在不同计算环境（如硬件、操作系统、编译器）中，仅需少量修改甚至无需修改便能编译和运行的能力，其衡量标准直接体现为跨平台适配所需付出的成本。然而，这并不意味着可移植性是绝对的教条。

在某些关键领域，如操作系统内核、高性能计算或驱动开发，为了榨取硬件极限性能、实现底层精细控制，主动采用不可移植的手艺（例如依赖特定编译器的扩展功能）是一种必要且合理的策略。 正如 Linux 内核的实践，它广泛启用 GCC 扩展特性，这虽以牺牲编译器可移植性为代价，却换来了无与伦比的效率与控制力，清晰地体现了其在设计目标上的优先级权衡。

C 语言标准明确定义了四种与可移植性相关的行为，它们为代码在不同平台间的表现提供了不同粒度的规范与保证。就可移植性高低而言，从上到下依次为：

1. 地域特定的行为（Locale Specific Behavior）；
2. 实现定义的行为（Implementation Defined Behavior）；
3. 未指明的行为（Unspecified Behavior）；
4. 未定义的行为（UB，Undefined Behavior）；

其中 UB 行为是 C/C++ 中令人生畏的一类行为，另一篇文章《C/C++ 的未定义行为（UB）》会展开说明了 UB 为什么会存在，以及对程序会带来什么影响。

C 标准定义的 4 种行为

一、地域特定的行为

就正确性而言， 地域特定行为是 C 标准明确认可并规范的合法行为。实现者（编译器/标准库）有权决定其具体表现，但必须将这些行为准确无误地记录在文档中。因此，应用程序可以完全信赖并安全地构建于这些行为之上，它们提供了稳定且可依赖的编程接口。

就可移植性而言， 此类行为在预设地域环境下具有高度的一致性。其表现差异主要源于对本地文化习俗的合理适配，这使得跨平台的行为变化被限制在可预见的范围内。为达成最佳的可移植性，建议在程序初始化时显式设定地域为 "C" 或 "POSIX" 标准，从而锁定统一的行为模式。正因其具备标准化的交互界面与可预测的变动逻辑，地域特定行为成为C语言中可移植性最高的行为类别之一。

比如：时间和日期的格式、决定哪些是小写字母等。（更多的示例能够参考 C23 标准的J.4 Locale-specific behavior章节或早期标准的相关章节）

二、达成定义的行为

就正确性而言， 实现定义的行为是 C 标准明确允许的合法行为。虽然其具体表现由编译器或系统环境自行决定，但标准强制要求所有实现必须将这类行为的选择和效果明确记录在官方文档中。因此，程序完全可以安全地依赖这些行为，它们为开发者提供了在标准框架内可预测且稳定的编程基础。

就可移植性而言， 此类行为在确定的编译器和目标环境下具有可靠的稳定性。由于实现细节已被文档化且通常保持向后兼容，在同一平台使用相同编译器工具链时，其表现高度一致。然而，当跨越不同编译器、操作系统或硬件架构时，这些建立定义的行为则可能表现出差异，因此依赖此类特性的代码在跨平台移植时需要额外的验证与适配工作。

1、执行环境支持哪些信号，以及它们的语义和默认的信号处理函数就是比如：有符号整数右移时最高比特位填充 0 还等。（更多的示例可以参考 C23 标准的J.3 Implementation-defined behavior章节或早期标准的相关章节）

三、未指明的行为

就正确性而言， 未指定行为属于 C 标准所允许的合法行为，但其具体实现方式并未被严格限定。它主要包括两种情形：一是使用未指明的值，二是标准提供多种可选处理路径而编译器可自由择一执行。尽管编译器有权决定其具体行为，但并无义务将其记录于文档中，甚至同一编译器的不同版本之间也可能存在差异。因此，软件不应依赖此类行为的具体表现，否则将引入潜在的不确定性。

就可移植性而言， 未指定行为在不同编译环境或同一编译器的不同版本中可能呈现不一致的结果，即使编译器和平台保持不变，其具体实现也无法保证长期稳定。由于缺乏文档约束与跨版本一致性承诺，依赖此类行为的代码在移植过程中面临较高风险，因此其在可移植性维度上的评价较低。

比如：函数实参求值的顺序、预处理时 ## 运算符的求值顺序等。（更多的示例可以参考 C23 标准的J.1 Unspecified behavior章节或早期标准的相关章节）

这里就 未指明的值（Unspecified Value）进行展开说明：

• C 语言中对象就是执行环境中的一个内存区域，其中的内容就是该对象的值（C23：3.18 object）；
• 对象的值本质上是一个位模式，对象的类型决定了如何解释这个位模式：
  • 位模式可能表示一个确定的有效值：
    • 例如使用 int 类型存储整数 100；
    • 有效的，但其具体内容既不受 C 标准规定，也不由编译器明确承诺，因此脚本不应依赖或预设其具体取值，否则将损害代码的正确性与可移植性。典型的例子包括：结构体或联合体为内存对齐而填充的字节内容，以及整数右移操作时高位所填充的比特值。这类由完成决定、但未予明确定义的值，在 C 标准中被统一归类为就是然而，某些对象的值虽然本身未指明的值。它们属于语言意义上的合法值，而使用这类值所产生的行为，则被定义为未指明行为；
  • 位模式表示的可能是一种非法状态：
    • 非值表示（Non Value Representation）（C23：3.24 non-value representation）用于标识一种“非法状态”。在 C23 标准之前，这一概念被称为就是是对象在存储层面的一种合法位模式，但它并不用于编码具体数值，而陷阱表示（Trap Representation）。引入此类表示的主要目的在于辅助调试：例如，编译器可将未初始化的对象显式设置为非值表示，后续任何读取该对象的操作都将触发陷阱，从而即时暴露程序错误；
    • 是否支持非值表示属于实现定义的行为。帮助该特性意味着编译器和目标 CPU 必须为该类型对象至少预留一个专用的位模式以标识非法状态，并且每次读取对象时都需执行合法性检查，这无疑会引入额外的运行时开销，降低执行效率。因此，目前主流的编译器和 CPU 架构普遍不帮助此特性，并对其持反对态度。不过也存在少数例外，例如 Itanium 架构 CPU 就利用其特有的 NaT（Not a Thing） 机制，为整数类型建立了非值表示；
• 通过而正如上文所述，几乎所有的编译器和 CPU 都不支持非值表示，所以能够近似地认为对象的任意一个位模式表示的都是该对象值域中的某个具体值。要是标准没有强制规定该值是多少，那么它就是未指明的值，程序的逻辑就依赖这个值；

四、未定义的行为（UB）

就正确性而言， 未定义行为属于软件中的错误与无效状态。C 标准对此类行为未施加任何约束，编译器可采取任意方式进行处理——包括（但不限于）产生看似符合逻辑却实际错误的结果、跳过相关检查、甚至直接终止程序。因此，程序中应严格避免出现未定义行为，更不应以任何形式依赖其表现。

就可移植性而言， 未定义行为在标准明确定义的四类行为中具有最高的不确定性与最差的移植前景。其具体表现不仅随编译器、运行平台或环境设置的变化而无法预测，甚至在同一环境下的不同执行中也可能出现不一致。这种根本上的不可靠性，使得含有未定义行为的代码几乎不具备实际的可移植价值。

虽然最终的决定权都交给编译器，但 UB 和其他 3 种行为核心的区别在于，UB 意味着程序 BUG 而不是特性。

比如：运用未初始化的局部变量、有符号整数的溢出、除以 0 或对 0 取余数、位移量超过类型的最大位宽、违反严格别名规则、数组下标越界、修改字符串常量的值、对空指针解引用 等（更多的示例可以参考 C23 标准的J.2 Undefined behavior章节或早期标准的相关章节）。

小结

行为	标准约束	程序中是否能够出现这类行为	程序是否可以依赖这类行为
地域特定的行为	编译器自行决定，但需文档化	✔	✔
实现定义的行为	编译器自行决定，但需文档化	✔	✔
未指明的行为	标准提供多个方案，编译器自由选择	✔	✗
未定义的行为	编译器自行决定	✗	✗