C 语言的符合性判断容易出错，根源在于标准把行为分成几类，而这几类的含义经常被混着说。标准定义里，实现定义行为要求实现做出选择并记录在文档中，未定义行为是标准不施加任何要求，未指定行为允许实现从若干可能中任选而不必说明。三者对应的代码风险完全不同。把未定义行为当成实现定义行为来依赖，是移植时最常见的误判来源。
三类行为到底差在哪
实现定义行为的关键在于有文档可查。整数除法的舍入方向、有符号整数右移的行为、某些类型转换的结果，标准要求实现选择一种并写进文档。写代码时可以依赖，前提是把编译器文档当接口。
未指定行为的自由度在于每次求值都可能不同。函数参数的求值顺序是典型例子，标准不规定先算哪个。同一份代码在不同编译器、甚至同一编译器的不同优化档位下都可能不同。
未定义行为最彻底。标准对程序的行为不做任何要求，编译器可以在编译期假定它不会发生，进而做出让源码看起来不再成立的变换，某些路径在开优化后行为完全改变就属于这一类。
为什么标准版本这件事先要说清楚
ISO C 的最新版本是 ISO/IEC 9899 的 2024 年版，通常称为 C23，它替代了此前的 C17。有一件事需要分清，编译器对标准的支持进度与标准本身是两回事，宣称支持某个标准的编译器，实际子集可能仍有差异。
语言属性的名称和可用性也有版本门槛。typeof、constexpr、nullptr_t、__VA_OPT__ 这些在 C23 才进入标准，更早的编译器可能以扩展形式提供相似能力，换编译器后可能编译失败。
代码里应当明确写出目标标准，不要依赖默认值。默认档位随编译器版本变化，升级工具链时这类隐式变化最容易造成回归。
怎么系统地找出来
- 把目标标准写进构建配置，并在源码里用条件编译明确区分标准版本。
- 打开尽可能多的警告并当错误处理。悬垂指针、隐式函数声明、类型截断这些问题，编译器大多已经能报出来。
- 用多种编译器交叉编译同一份代码。不同实现擅长抓的问题不一样，交叉验证能暴露对单一实现的依赖。
- 在 CI 里同时跑消毒器。地址消毒器抓内存越界和释放后使用，未定义行为消毒器抓对齐错误与有符号溢出。
- 用静态分析器检查移植性问题，重点看类型宽度、字节序和对齐的假设。
- 对已知的未定义行为热点做代码审计，包括数组越界、空指针解引用、有符号整数溢出和严格别名规则。
几个高频误判点
有符号整数溢出不会绕回。标准未定义这个行为，编译器可能利用它优化掉溢出检查。需要绕回语义时应当使用无符号类型。
严格别名规则容易被忽视。通过不兼容类型的指针访问同一块内存是未定义行为，常见的字节级操作和类型双关写法都可能踩到。
结构和联合体的填充字节内容不确定，用它做比较或哈希会得到不稳定结果。跨网络传结构体时，字段宽度、字节序和填充都要显式处理。
char 是否有符号由实现决定。把它当成确定有符号或无符号来用，换平台后就可能出错。
常见问题
开了 -std=c23 就符合 C23 了吗。不保证。该选项约束的是编译器接受的语法和语义档位，实现完整程度和库支持要单独确认。
多个编译器上都编过就没问题了吗。提高了信心，但不足以证明。未定义行为可能在某个特定优化组合下才显形。
未定义行为一定会崩溃吗。不一定。更多时候它表现为结果不确定，或者在升级编译器之后突然改变行为。