4. 基础数据类型规则：基本类型的使用限制与复合类型规范

数据类型这件事，说起来基础，但恰恰是嵌入式C代码里最容易埋雷的地方。我见过不少项目，跑着跑着出问题了，最后定位到根源——就是某个变量类型用错了，或者结构体对齐没处理好。MISRA-C 在 Rule 10.1 到 10.8 这一块，说白了就是帮你把这些坑提前堵上。

4.1 基本类型的使用限制（Rule 10.1-10.8）

MISRA-C 对基本类型的态度很明确：能用显式就用显式，别搞隐式转换。为什么呢？因为隐式转换在编译器和人眼之间，经常产生「我以为」和「实际是」的偏差。

4.1.1 基本类型类别划分

MISRA-C 把基本类型分成这么几类，你心里要有数：

类别	包含类型	典型场景
布尔型	bool（_Bool）	条件判断、标志位
字符型	char, signed char, unsigned char	字符串、字节流
有符号整型	signed int, signed short, signed long, signed long long	计数、差值、有符号运算
无符号整型	unsigned int, unsigned short, unsigned long, unsigned long long	位掩码、索引、大小
浮点型	float, double, long double	传感器数据、PID计算

Rule 10.1 要求：表达式中不允许混合使用不同类别的操作数。举个例子：

/* 违反 Rule 10.1 */
uint8_t a = 10;
bool b = true;
if (a && b) {   /* 错误：uint8_t 和 bool 混合使用 */
    /* ... */
}

/* 正确做法 */
if ((a != 0) && b) {  /* 显式转换为布尔表达式 */
    /* ... */
}

我个人习惯是，所有条件判断里，变量都写成 var != 0 或者 var == 0 的形式。看着啰嗦，但可读性和安全性都上去了。

4.1.2 复合表达式的类型规则

Rule 10.4 到 10.8 主要管的是复合表达式里的类型问题。我挑几个重点说：

• Rule 10.4：移位操作符的操作数必须是无符号整型。原因很简单——有符号数的右移是「实现定义」行为，不同编译器结果可能不一样。
• Rule 10.5：逻辑操作符（&&、||）的操作数必须是布尔型。别写 if (x) 这种，要写 if (x != 0)。
• Rule 10.6：复合赋值操作符（+=、-= 等）的右操作数类型必须与左操作数「本质类型」一致。

4.2 typedef 与自定义类型的规范

typedef 用好了是神器，用烂了是灾难。MISRA-C 对 typedef 的要求，核心就一句话：别让 typedef 隐藏了类型的关键信息。

4.2.1 命名规范

我建议团队里统一一个命名风格。比如：

/* 推荐风格：类型名加 _t 后缀 */
typedef uint32_t  timestamp_t;
typedef int16_t   speed_t;
typedef struct {
    uint8_t  id;
    uint16_t value;
} sensor_data_t;

/* 不推荐：没有明确后缀，容易混淆 */
typedef uint32_t  TIMESTAMP;
typedef int16_t   SPEED;

Rule 8.3 和 Rule 8.4 其实也跟 typedef 相关——所有类型定义必须在头文件中声明，并且一个文件里不要重复定义同名类型。

4.2.2 避免「过度封装」

有些团队喜欢把所有基本类型都用 typedef 包一层：

/* 过度封装，不推荐 */
typedef unsigned char   byte_t;
typedef unsigned int    word_t;
typedef unsigned long   dword_t;

/* 更好的做法：直接用标准类型 */
/* uint8_t, uint32_t 已经足够清晰 */

为什么我不推荐这么干？因为 byte_t 到底是有符号还是无符号？不同人理解不一样。直接用 uint8_t，全世界都看得懂。

4.3 复合类型（结构体、联合体）的 MISRA 要求

结构体和联合体在嵌入式里太常用了。MISRA-C 对它们的要求，主要集中在初始化、内存布局和访问方式上。

4.3.1 结构体的初始化

Rule 9.1 到 9.3 要求：结构体变量必须完全初始化。不能只初始化一部分成员，剩下的靠「运气」。

typedef struct {
    uint8_t  x;
    uint16_t y;
    uint32_t z;
} point_t;

/* 违反 Rule 9.1：只初始化了部分成员 */
point_t p1 = {10, 20};  /* z 未初始化 */

/* 正确做法：使用 designated initializer（C99 起支持） */
point_t p2 = {
    .x = 10,
    .y = 20,
    .z = 0
};

/* 或者全量初始化 */
point_t p3 = {10, 20, 0};

我个人习惯用 designated initializer。为什么？因为成员顺序一变，位置初始化就全乱了。用名字赋值，顺序随便调。

4.3.2 联合体的使用限制

联合体在 MISRA-C 里是个「敏感话题」。Rule 19.2 明确说：不允许使用联合体来 reinterpret 数据。说白了，别用联合体做类型双关（type punning）。

/* 违反 Rule 19.2：用联合体做类型双关 */
typedef union {
    float    f_val;
    uint32_t i_val;
} float_bits_t;

float_bits_t fb;
fb.f_val = 3.14f;
uint32_t bits = fb.i_val;  /* 未定义行为！ */

/* 正确做法：用 memcpy 或显式转换 */
float f = 3.14f;
uint32_t bits;
memcpy(&bits, &f, sizeof(bits));  /* 明确定义的行为 */

你想想看，为什么 MISRA 禁止联合体双关？因为不同编译器的内存布局、字节序、对齐方式都可能不一样。你今天在 ARM 上跑得好好的，明天换到 RISC-V 上，结果可能就变了。

4.3.3 结构体的内存布局与对齐

嵌入式开发里，结构体对齐是个大问题。MISRA-C 虽然没有直接规定对齐方式，但 Rule 8.12 要求：结构体成员之间不能有未命名的填充。也就是说，你要明确知道你的结构体在内存里长什么样。

/* 可能产生填充的结构体 */
typedef struct {
    uint8_t  a;   /* 偏移 0 */
    uint32_t b;   /* 偏移 4（有 3 字节填充） */
    uint16_t c;   /* 偏移 8 */
} __attribute__((packed)) packed_t;  /* 使用 packed 消除填充 */

/* 更好的做法：按大小排序成员，减少填充 */
typedef struct {
    uint32_t b;   /* 偏移 0 */
    uint16_t c;   /* 偏移 4 */
    uint8_t  a;   /* 偏移 6 */
} optimized_t;    /* 总大小 8 字节，无填充 */

4.4 知识体系总览

下面这张图把本章的核心知识点串起来了。你可以把它当作一个快速索引：

4.5 避坑指南与实战建议

最后，我把自己这些年积累的几个「血泪教训」列出来，你写代码的时候多留个心眼：

1. 别信「默认初始化」：局部变量、结构体成员，编译器不保证给你清零。每次都要显式初始化。
2. 联合体别乱用：除了 MISRA 禁止的类型双关，联合体在大小端不同的平台之间传输数据也会出问题。能用结构体就别用联合体。
3. typedef 别藏指针：比如 typedef uint32_t* paddr_t;，别人看到 paddr_t 不知道是指针，容易误用。我建议指针类型不要用 typedef 隐藏。
4. 结构体对齐要显式控制：特别是跟硬件寄存器或者通信协议打交道的时候，用 __attribute__((packed)) 或者手动填充字节。