C3 语言在 2026 年 5 月发布的 0.8.0 版本中完成了一次根本性的设计转变：将默认的大小类型从无符号改为有符号。这一变化并非心血来潮，而是五年实践中积累的深刻教训。C3 官方博客将这次变更称为 “szmageddon”（取自 size-zmageddon），足见其影响之深远。本文将深入分析无符号类型在系统编程中的根本性陷阱，以及有符号优先设计如何从根本上提升代码安全性。
无符号类型的系统性陷阱
无符号类型在 C、C++、Rust 和 Zig 等系统编程语言中被广泛用于表示大小和索引，这背后有着历史原因：C 标准将sizeof的返回类型定义为size_t（无符号），从此无符号算术成为 C 代码中的常见模式。然而，这一设计选择带来了系统性的安全问题。C3 团队在五年间反复遭遇以下几类 bug：
第一类是最经典的循环递减问题。当使用无符号类型作为循环计数器时，写成for (uint x = 10; x >= 0; x--)会导致无限循环，因为无符号整数永远不可能小于零。这类 bug 在 C3 中被检测到并拒绝编译，但这恰恰说明了问题的普遍性。C3 甚至明确拒绝在宏之外对无符号类型执行x >= 0这样的比较，因为这个表达式对无符号类型永远为真。
第二类陷阱涉及有符号与无符号的混合比较。考虑以下代码：uint a = 0; int b = -1; if (a > b)。在 C 语言中，两者都会被提升为无符号类型，-1 变成一个巨大的无符号值，导致比较结果与预期完全相反。C3 实现了安全的有符号 / 无符号比较来规避这一问题，但这种补丁式的解决方案恰恰暴露了更深层的设计缺陷。
第三类，也是最危险的陷阱，出现在模运算和除法中。C3 原本设计int + uint的结果类型为int，以减少隐式转换为无符号的情况。然而，当执行(foo + a) % 2且foo超过INT_MAX时，结果变得完全不可理解 —— 正确的写法应该是(foo + a) % 2U。这个问题的隐蔽性在于：它在大多数情况下 “恰好能工作”，使得错误极其难以发现。
环缓冲区的无符号困境
无符号类型的另一个典型陷阱体现在环缓冲区的实现中。假设需要计算带偏移量的索引，使用有符号类型时，常见的解决方案是((start + offset) % length + length) % length—— 只要 offset 为负数且不超过 length，这个公式就能正确工作。然而，当代码库使用无符号大小类型时，开发者很容易写出((start - offset_back) % length + length) % length这样的代码，这在逻辑上是错误的，但编译器无法检测出问题。这种错误有时会 “碰巧” 正确运行，使得调试更加困难。正确的无符号版本需要更复杂的表达式：(start + length - (offset_back % length)) % length。无论编译器对无符号和混合类型转换设置何种规则，都无法在编译期捕获第一种错误写法。
有符号优先的设计论证
C3 团队最终意识到，无符号类型的根本问题在于其边界行为。有符号 32 位整数的边界大约在正负 20 亿，而无符号 32 位整数的边界在 0 和约 40 亿之间。无符号整数的 “不安全” 边界距离零更近，这在模运算等场景中造成的问题远比有符号类型严重。此外，有符号溢出通常产生明显无效的负数，而无符号溢出往往产生看似合理但实际错误的值。在现代 64 位机器上，在使用完整有符号 64 位整数之前早就耗尽了内存，因此无符号类型的 “额外范围” 优势在实际应用中几乎毫无意义。
Go 语言作为一门由深谙 C++ 问题的工程师创建的底层语言，毅然选择了有符号大小类型；Java 则在 90 年代完全移除了无符号类型以消除一大类常见 bug。这些先行者的经验表明，有符号优先不是保守的选择，而是经过验证的正确方向。
C3 0.8.0 的实际变更
在 0.8.0 版本中，C3 将默认大小类型isz重命名为sz，与usz形成清晰的对称 pair。这一命名更改具有重要的语义暗示：开发者应当优先使用sz而非usz。更重要的是，C3 完全移除了有符号与无符号类型之间的隐式转换 —— 此前这种转换被保留是因为大小类型默认无符号，转换不可避免，但现在既然有符号成为默认，隐式转换变得不再必要。
C3 团队在重构过程中发现，仅仅将uint和ulong替换为有符号版本，就暴露了大量可疑或错误的代码。代码整体上变得更简单、更易于推理。团队成员坦言，在最初做出改变时感到 “尴尬” 和 “仿佛在做什么禁止的事”，这恰恰说明了无符号优先的思维惯性有多么根深蒂固 —— 即使是最了解问题的语言设计者，也需要刻意努力才能摆脱这一思维定式。
工程实践的启示
C3 的这次转变给系统编程语言设计者提供了重要启示：无符号类型并非 “自然” 适合表示大小，而是历史偶然的结果。当语言默认使用有符号大小类型时，代码中的类型转换需求大幅减少，边界情况的处理变得更直观，编译器也能更有效地捕获潜在错误。对于正在设计新系统编程语言或重构现有代码库的团队而言，C3 五年的实践经验表明：有符号优先不仅是更安全的选择，也是更简单、更可维护的选择。
资料来源：C3 官方博客（c3-lang.org/blog/）与 C3 语言类型文档（c3-lang.org/language-overview/types/）