📚 课程目录第4章基本数据类型

4. 基本数据类型：整型类型的使用规范、隐式类型转换的陷阱、typedef与#define的选择、我踩过的类型混用坑

各位同学，咱们今天聊一个看似基础、实则坑最多的话题——整型类型。说实话，我见过太多项目因为类型问题翻车了。轻则功能异常，重则安全漏洞被黑客利用。MISRA C 里关于整型的规则，那真是用血泪换来的。

4.1 整型类型的使用规范

先问大家一个问题：int 到底有多宽？很多人想都不想就说 32 位。但我在一个嵌入式项目里就遇到过，某款 16 位 MCU 上 int 就是 16 位的。代码从 32 位平台移植过来，直接崩了。

MISRA C 怎么要求的？它要求你明确使用 stdint.h 里的定宽类型：

/* 错误示范：依赖编译器 */
int counter;          /* 可能是16位，也可能是32位 */
unsigned int delay;   /* 移植性差 */

/* 正确做法：明确宽度 */
int32_t counter;      /* 32位有符号 */
uint32_t delay;       /* 32位无符号 */
uint8_t byte_val;     /* 8位无符号 */

核心原则：永远不要假设基本类型的宽度。用 int32_t、uint16_t 这类定宽类型，让代码的行为一目了然。

我个人习惯，在项目一开始就定义一个类型别名头文件。把所有用到的整型都列清楚。这样后面的人接手，也不会猜来猜去。

4.2 隐式类型转换的陷阱

隐式类型转换，说白了就是编译器偷偷帮你做类型转换。你以为它在帮你，其实它在坑你。

看这个经典例子：

uint16_t a = 1000;
uint16_t b = 2000;
uint16_t c;

c = (a + b) / 2;  /* 这里有问题！ */

/* 发生了什么？
 * a + b 的结果是 3000，没问题
 * 但 a 和 b 都是 uint16_t，运算时被提升为 int
 * 如果 int 是 16 位，3000 没溢出
 * 但如果 a = 40000, b = 40000 呢？
 * 40000 + 40000 = 80000，16位 int 装不下！
 */

为什么会这样？C 语言有个“整型提升”规则。小于 int 的类型，在运算前都会被提升到 int。如果 int 只有 16 位，那 uint16_t 提升上去还是 16 位，溢出风险一点没少。

避坑指南：我曾经在一个电机控制项目里，就因为这种隐式提升导致电流采样值溢出。电机直接过流保护，整条产线停了两个小时。从那以后，我所有中间运算结果都强制用 int32_t 或更大的类型。

MISRA C 规则 10.1 到 10.8 全是讲这个的。核心就一句话：不要依赖隐式转换，显式写出你的意图。

/* 安全写法 */
uint16_t a = 40000;
uint16_t b = 40000;
uint32_t c;

c = ((uint32_t)a + (uint32_t)b) / 2;  /* 显式转换，安全 */

4.3 typedef 与 #define 的选择

很多新手喜欢用 #define 定义类型别名：

/* 错误示范 */
#define INT32 int32_t
#define UINT16 unsigned short

这有什么问题？你想想看，#define 只是文本替换，编译器根本不知道你定义了一个“类型”。调试的时候，符号表里看到的还是 int32_t，不是 INT32。而且 #define 没有作用域限制，一不小心就污染了全局命名空间。

我建议用 typedef：

/* 正确做法 */
typedef int32_t my_int32_t;
typedef uint16_t my_uint16_t;

typedef 是编译器一级的类型定义，有类型检查，有作用域，调试器也能识别。说白了，typedef 是“创造了一个新类型”，而 #define 只是“找了个替身”。

特性	typedef	#define
类型检查	有	无
作用域	遵循 C 作用域规则	全局有效
调试器支持	能识别类型名	只看到原始类型
可读性	好	差（宏展开后可能混乱）
MISRA C 推荐	推荐	不推荐用于类型定义

小技巧：如果你需要定义的是“类型”，用 typedef。如果你需要定义的是“常量”或“表达式”，用 #define。两者分工不同，别混用。

4.4 我踩过的类型混用坑

说到这个，我可太有发言权了。给大家讲三个真实案例。

案例一：有符号与无符号的“爱恨情仇”

int32_t signed_val = -10;
uint32_t unsigned_val = 20;

if (signed_val < unsigned_val) {
    /* 你以为会执行？错了！ */
}

/* 为什么？
 * 比较时，signed_val 被隐式转换为 uint32_t
 * -10 变成 0xFFFFFFF6，也就是 4294967286
 * 4294967286 < 20 ？ 不成立！
 */

我当时在一个安全气囊控制器里写了类似的代码。测试的时候一切正常，因为测试用例里 signed_val 都是正数。结果量产之后，某个特殊工况下 signed_val 变成了负数，比较逻辑直接反了。安全气囊该爆的时候没爆，不该爆的时候爆了。嗯，那段时间我天天被叫去开会。

案例二：位宽不匹配的赋值

uint32_t big_val = 0x12345678;
uint16_t small_val;

small_val = big_val;  /* 截断！只保留低16位 0x5678 */

这种错误在 MISRA C 里属于“违规赋值”。编译器可能只给个警告，但很多人直接忽略了。我建议开启编译器的“警告当作错误”选项，让这种代码根本编译不过去。

案例三：枚举类型与整型的混用

typedef enum {
    STATE_IDLE = 0,
    STATE_RUNNING,
    STATE_ERROR
} system_state_t;

system_state_t state = STATE_IDLE;
uint8_t raw_value;

raw_value = state;  /* 隐式转换，MISRA C 禁止 */

/* 正确做法 */
raw_value = (uint8_t)state;  /* 显式转换 */

枚举类型本质上是 int，但 MISRA C 要求你不能把它当整型随便用。我见过有人把枚举值直接做位运算，结果枚举值变了，整个状态机都乱了。

总结一下我的经验：

所有类型转换都显式写出来，别指望编译器帮你兜底
有符号和无符号不要混用，实在要混用就加显式转换
不同位宽的类型赋值时，先确认会不会截断
枚举就是枚举，别当整型用

下面这张图，是我自己总结的整型类型使用决策流程。每次写代码前过一遍，能避免 90% 的类型问题。

好了，这一章的内容就这些。类型问题看着简单，但真踩坑的时候，代价往往很大。希望大家写每一行代码的时候，都想想我说的这些案例。别让编译器替你做了决定，你自己才是代码的主人。