Mdr-C-Tutorial

主题

遵从性和行为 ​

1. 为什么先讲行为分类 ​

C 标准不会把所有问题都写成“对”或“错”。它会区分“实现决定”“结果不唯一”“完全无保证”等多种情况。读标准文档、判断可移植性、排查线上问题，都依赖这套分类体系。如果把这些类别混在一起，很多问题会被误判为“编译器随机出错”。

2. 常见行为类别 ​

2.1 实现定义行为 ​

标准要求实现给出一种明确行为，并在文档中说明。例如 char 默认是有符号还是无符号，属于实现定义行为。工程上可以使用这类能力，但要通过文档或编译选项把前提写清楚。

2.2 未指明行为 ​

标准允许出现若干种结果，但不要求实现每次都做同样选择。例如某些表达式中子表达式的求值先后次序并未固定。代码如果依赖某一种求值次序，就会在不同编译器或不同优化级别下表现不一致。

2.3 未定义行为 ​

一旦触发，标准不再提供任何结果保证。越界访问、悬垂指针解引用、对同一标量对象进行无序修改都属于这一类。它最危险的地方在于：有时“看起来能跑”，但平台或优化变化后会立即失效。

c
#include <stdio.h>

int main(void) {
    int i = 1;
    int x = i++ + i++; /* 未定义行为 */
    printf("%d\n", x);
    return 0;
}

可能的输出（示例）：

bash

<输出与输入或平台相关，请以实际运行为准>

这里对同一标量对象 i 的两次修改没有确定先后关系，因此行为未定义，不能把某一次输出当成规则。

3. 遵从性 (Conformance) ​

遵从实现是指满足标准约束的编译器和库实现；遵从程序是指只依赖标准保证语义、在约束内运行的程序。项目代码中常说“严格遵从”，本质是减少实现细节依赖，让代码在更多平台上稳定工作。

4. 使用建议 ​

把编译告警当成设计反馈而不是噪声，在持续集成中开启 -Wall -Wextra -Wpedantic；对实现定义行为补充注释与构建约束；把可能触发未定义行为的写法改写为可证明正确的等价表达式。这不是形式主义，而是降低维护成本的直接手段。

5. 诊断与行为分类的关系 ​

需要诊断并不等于一定“有定义结果”，未触发诊断也不等于“完全安全”。理解行为分类时，要把“编译器是否报错”和“标准是否保证语义”分开判断。前者是实现反馈，后者是语言契约。

6. 一个排查顺序 ​

遇到“同一代码在不同平台表现不同”时，可以按这个顺序排查：先确认是否触发未定义行为，再确认是否依赖实现定义行为，最后确认是否落在未指明行为区间。把问题先归类再修复，通常比直接改语法更快找到根因。

7. 把行为前提写进接口注释 ​

当某段代码依赖实现定义结果（例如字节序、char 有符号性、浮点环境前提）时，最好把前提直接写在接口或模块注释中，而不是只留在构建脚本里。这样调用方在阅读接口时就能知道边界条件，减少“接口看起来通用、实际只适配一组实现”的误解。

c
#include <limits.h>

/* 前提：当前实现要求 plain char 为无符号。 */
#if CHAR_MIN < 0
#error "This module requires unsigned plain char"
#endif

运行结果：该代码块主要用于语法或结构说明，单独运行通常无终端输出。

8. 避免把“当前可用”误判为“标准保证” ​

很多不稳定写法在单一平台上长期“看起来可用”，并不代表它们处于标准保证范围。判断一段代码是否可靠时，应优先看标准语义类别，再看当前工具链表现。把这两个层次分开，才不会在迁移编译器或调整优化级别时遭遇突发故障。

c
int a[2] = {1, 2};

/* 反例：越界访问在某些环境“看起来可用”，但不受标准保证。 */
/* int x = a[2]; */

/* 正例：边界可证。 */
int y = a[1];

运行结果：该代码块主要用于语法或结构说明，单独运行通常无终端输出。