嵌入式C语言错误码选型：有符号还是无符号？

作为常年泡在嵌入式C代码里的开发者，我太懂这种纠结了！之前也在项目里跟团队掰扯过这个问题，结合自己踩过的坑和行业里的常见做法，给你捋捋清楚：

两种类型的核心差异与优劣 #

• 有符号类型（比如int/int32_t）：
  • 优势：天然支持「成功（0）」「错误（负数）」「额外状态（正数）」的三级区分，比如你想返回“操作部分完成”“资源不足但仍可继续”这类非错误状态，正数就能派上用场，确实能覆盖更多场景。
  • 注意点：要警惕符号溢出问题——比如错误码计算时不小心溢出变成正数，很容易被误判为成功；跨平台移植时还要注意符号位的扩展逻辑，避免32位/64位系统下出现异常。
• 无符号类型（比如unsigned int/uint32_t）：
  • 优势：没有符号扩展的隐患，数值范围全为非负，很多遗留代码用它是因为早期嵌入式系统逻辑简单，错误码只需要区分「成功（0）」和「失败（非0）」；而且和底层硬件寄存器的无符号属性匹配，能减少类型转换的麻烦。
  • 局限：没法用正数表达非错误状态，所有非0值都会被视为错误，要是想区分“警告”和“致命错误”，就得额外加参数或者用位掩码，反而增加代码复杂度。

行业里的潜规则：没有绝对标准，但有场景适配逻辑 #

你说查了Linux内核和Google C++风格没找到明确指引，其实是因为这俩场景的诉求不同：

• Linux内核里很多函数用int返回错误码（负数为错误，0为成功，正数有时用来返回实际操作字节数这类结果），但底层驱动里也会出现无符号状态码，核心是适配具体场景的需求。
• 嵌入式领域的遗留代码偏爱无符号，大多是因为早期系统资源紧张、逻辑简单，只需要“对/错”的判断，且当时编译器对无符号类型的优化更友好。

给你的选型建议 #

1. 优先对齐团队现有规范：如果项目里大部分遗留代码用无符号，除非有非常强的业务理由（比如必须区分多种非错误状态），否则尽量保持一致——代码一致性比个人偏好重要，能减少后续维护的混乱。
2. 新项目/重构场景：
   • 若系统需要区分「成功」「错误」「警告/部分成功」，果断用有符号固定宽度类型（比如int32_t），避免平台差异带来的问题。
   • 若系统逻辑简单，仅需“成功/失败”判断，或需要频繁与硬件寄存器、无符号API交互，用无符号固定宽度类型（比如uint32_t）也完全没问题。
3. 关键约定：不管选哪种，一定要统一规则——比如明确0代表成功，有符号类型约定负数为错误码、正数为状态；无符号类型约定非0为错误码，同时把所有错误码定义成枚举或宏，绝对不要散写魔法数字。

内容的提问来源于stack exchange，提问作者0xFAB