06.限定符与指针语义

目录介绍

• 1. 案例引入
  • 1.1 一段崩在哪
  • 1.2 顺藤摸到根因
  • 1.3 我们要回答什么
• 2. 架构概览
  • 2.1 三限定符全景
  • 2.2 与指针结合的维度
• 3. const指针三种形态
  • 3.1 指针自身不可变
  • 3.2 指向的内容不可变
  • 3.3 双重const的用法
  • 3.4 const的读写规则
• 4. const的编译期真相
  • 4.1 const不放在rodata
  • 4.2 const可以被绕过吗
  • 4.3 用const表达API契约
  • 4.4 const与代码正确性
• 5. volatile在硬件交互中的作用
  • 5.1 内存映射IO原理
  • 5.2 volatile禁止优化删除
  • 5.3 信号处理中的volatile
  • 5.4 setjmp与volatile
• 6. volatile不是同步工具
  • 6.1 多线程中的volatile
  • 6.2 内存屏障与原子操作
  • 6.3 volatile的正确对比
• 7. restrict别名优化
  • 7.1 别名拖慢
  • 7.2 restrict的编译期契约
  • 7.3 memcpy实现的restrict
  • 7.4 restrict误用导致UB
• 8. 限定符模式
  • 8.1 const防御性编程
  • 8.2 volatile在嵌入式驱动
  • 8.3 restrict的性能敏感区
• 9. 常见误用与反模式
  • 9.1 const的虚假安全感
  • 9.2 volatile的性能陷阱
  • 9.3 restrict与const混用
• 10. 综合案例串讲
  • 10.1 案例真相揭晓
  • 10.2 限定符实战决策树
  • 10.3 设计哲学回扣
  • 10.4 限定符速查

1. 案例引入

1.1 一段崩在哪

看一段在医疗设备固件中跑了两年后才暴露的代码——某次 FDA 审计时被发现血压读数"偶尔跳变"，但硬件传感器输出完全正常：

// bp_monitor.c —— 无创血压监护仪
#include <stdio.h>
#include <stdint.h>

/* 硬件寄存器——映射到物理地址 0x4000_3800 */
#define BP_SENSOR_DATA   (*(volatile uint32_t *)0x40003800)
#define BP_SENSOR_READY  (*(volatile uint32_t *)0x40003804)

/* 校准参数——出厂时写入，运行时绝不应被修改 */
static const float CALIBRATION_FACTOR = 1.023f;

/* 全局状态——标记是否有未处理的紧急读数 */
static volatile int emergency_flag = 0;

/* 配置结构体——传给各处理模块 */
typedef struct {
    const float *calib_factor;   /* ← 指向校准常量的指针 */
    int          sample_count;
} BPConfig;

/* 信号处理函数——硬件中断触发 */
void bp_isr_handler(void) {
    if (BP_SENSOR_READY & 0x01) {
        uint32_t raw = BP_SENSOR_DATA;
        if (raw > 0x80000000) {
            emergency_flag = 1;      /* ← volatile 写——其他线程可见 */
        }
    }
}

/* 主循环——读取并转换血压值 */
float read_blood_pressure(const BPConfig *cfg) {
    float sum = 0.0f;

    for (int i = 0; i < cfg->sample_count; i++) {
        /* 忙等——等待传感器就绪 */
        while (!(BP_SENSOR_READY & 0x01)) {
            /* ⚠️ 如果在 -O2 下，这个 while 可能变成死循环 */
        }

        uint32_t raw = BP_SENSOR_DATA;
        float pressure = (float)raw * (*cfg->calib_factor);  /* ← Line A */
        sum += pressure;
    }

    return sum / cfg->sample_count;
}

int main(void) {
    BPConfig cfg = {
        .calib_factor = &CALIBRATION_FACTOR,
        .sample_count = 10
    };

    while (1) {
        /* 定期重新校准（正常操作流程） */
        if (emergency_flag) {
            float bp = read_blood_pressure(&cfg);
            printf("紧急血压: %.1f mmHg\n", bp);
            emergency_flag = 0;
        }
    }
    return 0;
}

现象：

• 调试模式（-O0）：读数完全正常，校准因子 1.023 始终生效
• 发布模式（-O2）：偶发血压值偏离 ~30%，校准因子似乎"时而生效时而失效"
• 用 -O2 回放同一段传感器数据：同一套输入产生不同的输出

第一反应：硬件传感器有干扰？但换了标准信号源还是一样。是不是 CALIBRATION_FACTOR 被意外修改了？加了硬件断点——从未被写。

1.2 顺藤摸到根因

在 -O2 下的汇编中找答案（godbolt: gcc 14.1 -O2 -mcpu=cortex-m4）：

; read_blood_pressure 的核心循环——-O2 生成的汇编（简化）

; while (!(BP_SENSOR_READY & 0x01))
.L3:
    ldr    r3, [pc, #offset]       ; 从内存加载 BP_SENSOR_READY 的地址
    ldr    r3, [r3]                ; 读取寄存器值
    tst    r3, #1                  ; 测试 bit 0
    beq    .L3                     ; 为 0 → 循环

; float pressure = raw * calib_factor
    ldr    r3, [r4]                ; r4 指向 calib_factor
    vldr   s15, [r3]               ; 加载校准因子到浮点寄存器
    ...

; ⚠️ 注意！编译器把 cfg->calib_factor 加载到 s15 后，
;     后续的循环迭代复用了 s15 —— 不再通过 cfg->calib_factor 重读！
;     因为它看到 cfg->calib_factor 是 const float* ——
;     "指向的 const 不会变" —— 编译器把这个假设优化了

根因链条：

1. cfg->calib_factor 声明为 const float*，编译器认为它指向的数据永远不会被修改
2. 在 -O2 下，编译器把 *cfg->calib_factor 的值缓存在浮点寄存器 s15 中，循环迭代间不重读
3. 但是——其他代码路径通过 &CALIBRATION_FACTOR 的非 const 路径修改了它！
4. 检查代码发现——实际上没有任何代码修改 CALIBRATION_FACTOR。那为什么 -O0 和 -O2 结果不同？

再深入排查——发现 read_blood_pressure 并不是唯一的读取者。中断处理函数 bp_isr_handler 中访问 BP_SENSOR_DATA 没有用 volatile 修饰读取值本身，但 BP_SENSOR_DATA 是硬件寄存器——编译器在 -O2 下可能重排或合并对它的读取。

进一步发现：emergency_flag 声明为 volatile int（正确），但 read_blood_pressure 的主循环中没有访问它。问题出在编译器对 const float* 的激进优化——它假设被 const 修饰的指针所指向的值，在整个函数执行期间不会变化。然而在医疗设备的长运行时（数小时），校准因子确实会因为设备的自动校准线程（在另一个 .c 文件中，通过非 const 路径）被更新。

真正的根因：const 在 C 语言中只是编译期的承诺——"我不会通过这个指针修改它"。但如果有人通过另一个指针（非 const）同时访问同一块内存，编译器对此一无所知，它仍然假定 *cfg->calib_factor 不变——导致优化出错。这就是"别名（aliasing）"问题和 restrict 发挥作用的场景。

这段代码暴露了 6 个关于限定符的核心问题：

① const int *p 和 int * const p 有什么区别？               → 第 3 章
② const 真正保护了什么？为什么说它是编译期承诺？            → 第 4 章
③ volatile 的正确用法是什么？为什么 MMIO 必须用它？        → 第 5 章
④ 为什么 volatile 不能替代互斥锁？                         → 第 6 章
⑤ restrict 是什么？为什么它能翻倍 memcpy 性能？            → 第 7 章
⑥ 三个限定符如何组合使用？                                  → 第 8-9 章

1.3 我们要回答什么

这个案例就是本篇的主线。我们从 const 的三种指针形态出发，拆解 volatile 在硬件交互中的不可替代性，论证为什么 volatile 不是同步工具，最后用 restrict 解开"别名优化"之谜——并在第 10 章回到这个医疗设备案例，用正确的限定符组合根治之。

三限定符全景 (第 2 章)
   ↓
const 的三种形态 + 编译期真相 (第 3-4 章) ─→ 解开①~②
   ↓
volatile 硬件交互 (第 5 章) ─→ 解开③
   ↓
volatile 不是同步工具 (第 6 章) ─→ 解开④
   ↓
restrict 别名优化 (第 7 章) ─→ 解开⑤
   ↓
工程模式 + 安全边界 (第 8-9 章) ─→ 解开⑥
   ↓
综合案例 (第 10 章) ─→ 完整修复

2. 架构概览

2.1 三限定符全景

C 语言有三个影响编译器和硬件行为的类型限定符：

┌──────────────────────────────────────────────────────────────┐
│  限定符     │  核心语义         │  主要场景                   │
├─────────────┼───────────────────┼─────────────────────────────┤
│  const      │  编译期不可修改   │  API 契约、只读参数         │
│  volatile   │  每次访问必读内存 │  MMIO、信号处理、setjmp     │
│  restrict   │  独占该内存区域   │  性能优化、别名消除         │
└──────────────────────────────────────────────────────────────┘

2.2 与指针结合的维度

限定符与指针结合时，产生一个二维决策矩阵：

           指向的内容          指针本身
           ↓                   ↓
const:    const int *p        int * const p
          "不能通过 p 改 *p"   "不能改 p 的指向"

volatile: volatile int *p     int * volatile p
          "每次 *p 必读内存"   "每次用 p 必读 p 本身"

restrict: int * restrict p    (restrict 只修饰指针变量本身)
          "只有 p 能访问那片内存"

组合读法口诀——从右向左读，先读指针，再读指向：

const    int  *       p   → p 是指针，指向 const int
          ↑           ↑       (指向的内容不可变)
          从右向左读

int      *    const   p   → p 是 const 指针，指向 int
               ↑      ↑       (指针本身不可变)

const    int  * const p   → p 是 const 指针，指向 const int
          ↑         ↑  ↑       (指针和内容都不可变)

3. const指针三种形态

3.1 指针自身不可变

int x = 10, y = 20;

int * const p = &x;      /* p 自身不可修改——终身绑定到 x */

*p = 30;                 /* ✅ 可以通过 p 修改 x */
// p = &y;               /* ❌ 编译错误：不能修改 p 的指向 */

/* 汇编——指针常量在编译后和普通指针一样，只是编译器不允写 */

典型用途——函数内的只读迭代器：

void process(int *arr, size_t n) {
    int * const end = arr + n;   /* end 终身指向数组末尾 */
    for (int *p = arr; p < end; p++) {
        *p *= 2;                 /* 可以改数据 */
        // end = something;      /* ❌ 不能改 end——编译期保护 */
    }
}

3.2 指向的内容不可变

这是最常见的 const 用法：

const int *p;             /* 等价于 int const *p */
int x = 10;

p = &x;                   /* ✅ 可以改 p 的指向 */
// *p = 20;               /* ❌ 编译错误：不能通过 p 修改 *p */

x = 20;                   /* ✅ 但可以直接通过 x 修改！const 只限制 p 这条路径 */

关键理解：const int *p 不是说 *p 指向的内存是只读的——它只是说"通过 p 这条路径不能修改"。如果存在另一条非 const 路径，那块内存仍然可以被修改。

3.3 双重const的用法

const int * const p = &x;
/* p 不能改指向，不能通过 p 改 *p——最严格的只读保护 */

/* 典型用途——指向 ROM/Flash 中固定数据的指针 */
const char * const error_msg = "FATAL ERROR";  /* 字符串在 rodata，指针不移 */

3.4 const的读写规则

非 const → const 转换（安全——隐式）：

int x = 42;
const int *p = &x;        /* ✅ 隐式转换——"承诺只读" */

const → 非 const 转换（危险——需显式转换）：

const int x = 42;
// int *p = &x;           /* ❌ 编译警告：丢弃 const 限定符 */
int *p = (int *)&x;       /* ⚠️ 显式转换——绕过编译器保护 */
*p = 99;                  /* UB——修改 const 对象！ */

4. const的编译期真相

4.1 const不放在rodata

疑惑：const int x = 5; 放在 .rodata 段吗？

论证：

/* 全局 const——通常放在 .rodata */
const int global_const = 100;     /* .rodata 段——真正的只读 */

/* 局部 const——放在栈上！ */
void func(void) {
    const int local_const = 200;  /* 栈上——硬件事不可写，但逻辑上是只读的 */
    int *p = (int *)&local_const;
    // *p = 300;                  /* UB！即使栈可写，标准禁止修改 const */
}

结论：const 不决定变量在哪个段——决定的是变量的存储期（全局→静态段，局部→栈）。const 只是一个编译器承诺："通过这个名字，我不会写它"。

4.2 const可以被绕过吗

const int x = 10;
int *p = (int *)&x;
*p = 99;                   /* ❌ UB！即使编译器通过，结果是未定义的 */

/* 编译器在 -O2 下的优化结果 */
printf("%d\n", x);         /* 可能输出 10（编译器内联了初始值） */
printf("%d\n", *p);        /* 可能输出 99（从内存重新读了） */
/* ⚠️ 同一个变量，两个输出可能不同！——这就是 UB 的可怕之处 */

const 不是安全锁——它是安全承诺：如果你遵守承诺（不修改 const 对象），编译器保证正确的行为。如果你用强制转换打破承诺，结果是 UB。

4.3 用const表达API契约

/* API 设计——const 用于声明"输入只读"参数 */
size_t my_strlen(const char *s);              /* s 的内容不会被修改 */
int    my_strcmp(const char *a, const char *b); /* a 和 b 都不被修改 */
void  *my_memcpy(void * restrict dest,         /* dest 可写 */
                 const void * restrict src,   /* src 只读——const 契约 */
                 size_t n);

这是 const 最强大的用途——它让函数签名自己表达意图：

• const char * → "我不会通过这个指针写你的数据"
• const T *cfg → "这只是配置，不会被改动"

读 my_memcpy 的签名，一眼就知道 src 不会被改——这就是 API 文档直接嵌入在类型系统中的力量。

4.4 const与代码正确性

/* ❌ 没有 const——语义模糊 */
void update_config(int *timeout, int *retries) {
    *timeout = 30;      /* 改了 timeout */
    /* retries 呢？函数声明没说你不会改它——调用者无法信任 */
}

/* ✅ 有 const——语义清晰 */
void update_config(int *timeout, const int *retries) {
    *timeout = 30;
    // *retries = 3;    /* ❌ 编译器报错——保护调用者的数据 */
}

const 是给读代码的人看的，其次才是给编译器看的。一个函数签名的 const 越多，调用者越放心。

5. volatile在硬件交互中的作用

5.1 内存映射IO原理

嵌入式系统中，硬件寄存器映射到物理地址：

/* ARM Cortex-M 的 GPIO 寄存器 */
#define GPIOA_ODR  (*(volatile uint32_t *)0x40020014)  /* 输出数据寄存器 */
#define GPIOA_IDR  (*(volatile uint32_t *)0x40020010)  /* 输入数据寄存器 */

/* 点亮 LED */
GPIOA_ODR |= (1 << 5);     /* 写寄存器——硬件立即响应 */

/* 等待按键 */
while (!(GPIOA_IDR & (1 << 0))) {
    /* 必须用 volatile——否则编译器可能只读一次，死循环 */
}

如果没有 volatile：

; 汇编（-O2 优化，假设 GPIOA_IDR 没有 volatile）
    ldr    r3, [pc, #offset]    ; 读出寄存器地址
    ldr    r0, [r3]             ; 只读一次！——值存入 r0
.L2:
    tst    r0, #1               ; 永远测试同一个值
    beq    .L2                  ; ← 死循环！硬件的变化永远看不到

有 volatile 后：

.L2:
    ldr    r0, [r3]             ; 每次循环都重新读取！
    tst    r0, #1
    beq    .L2                  ; ← 正确——硬件信号变化能被看到

5.2 volatile禁止优化删除

/* 场景：向硬件发送一个空操作命令——写即生效，值从不被读回 */
void send_nop(void) {
    volatile uint32_t *cmd_reg = (volatile uint32_t *)0x40001000;
    *cmd_reg = 0x00000001;        /* 写寄存器——硬件即响应 */
    *cmd_reg = 0x00000002;        /* 再次写——必须有两次写 */
}

如果没有 volatile：

; -O2 优化后——编译器看到两次写同一个地址，认为第一写是死的
    mov    r3, #0x40001000
    mov    r2, #2
    str    r2, [r3]              ; ← 只写了第二次！硬件没收到第一次命令

有 volatile 后——两条 str 指令都被保留，硬件收到两次命令。

volatile 的核心语义：每一次 *p 的读写操作必须生成对应的内存访问指令，编译器不能省略、不能合并、不能重排 volatile 访问。

5.3 信号处理中的volatile

#include <signal.h>
#include <stdint.h>

volatile sig_atomic_t g_flag = 0;  /* ← 必须是 volatile + sig_atomic_t */

void handler(int sig) {
    g_flag = 1;                     /* 信号处理器中唯一安全的事：设标志 */
}

int main(void) {
    signal(SIGINT, handler);

    while (1) {
        if (g_flag) {               /* 每次循环都读内存——volatile 保证不优化掉 */
            printf("收到信号\n");
            g_flag = 0;
        }
        do_work();
    }
}

三重保障：

1. volatile → 每次访问 g_flag 都读写内存（不是寄存器缓存）
2. sig_atomic_t → 类型保证读写是原子的（硬件级别，不会被信号打断）
3. 不在信号处理器中做重操作 → 只设标志，主循环处理

5.4 setjmp与volatile

#include <setjmp.h>

jmp_buf env;

void risky_operation(void) {
    volatile int depth = 0;     /* ← 必须是 volatile！ */
    /* 如果没有 volatile——longjmp 后 depth 的值不确定 */

    depth++;
    if (depth > 100) longjmp(env, 1);

    /* ... */
}

int main(void) {
    if (setjmp(env) == 0) {
        risky_operation();
    } else {
        /* longjmp 后——栈帧还在但寄存器恢复了
           volatile 保证 depth 从内存读出而不是从寄存器恢复 */
    }
}

6. volatile不是同步工具

6.1 多线程中的volatile

这个错误极其普遍——不要在 C 语言中用 volatile 做多线程同步：

/* ❌ 危险的反模式——用 volatile 做"线程安全的 flag" */
volatile int ready = 0;
int data = 42;

/* 线程 A */
void producer(void) {
    data = 100;         /* ← 可能被编译器或 CPU 重排到 ready = 1 之后！ */
    ready = 1;          /* volatile 只保证这条写入不被优化，不保证顺序 */
}

/* 线程 B */
void consumer(void) {
    while (!ready) {}   /* volatile 保证每次循环都读内存 */
    printf("%d\n", data); /* 可能输出 42！——data 的写入可能在 ready 之前 */
}

为什么 volatile 不够：

1. CPU 可能重排指令——data = 100 和 ready = 1 在 CPU 的乱序执行中顺序不定
2. 编译器可能重排——volatile 只保证 volatile 访问之间的顺序，不保证非 volatile 访问
3. 缓存一致性——一个 CPU 核心写的 volatile 值，另一个核心可能读到旧的缓存

正确的做法——C11 原子操作：

#include <stdatomic.h>

atomic_int ready = 0;
int data = 42;

void producer(void) {
    data = 100;
    atomic_store_explicit(&ready, 1, memory_order_release);  /* 保证 data 先于 ready */
}

void consumer(void) {
    while (!atomic_load_explicit(&ready, memory_order_acquire)) {}
    printf("%d\n", data);  /* ✅ 保证看到 data = 100 */
}

6.2 内存屏障与原子操作

volatile 提供的能力：                    原子操作额外提供的能力：
┌─────────────────────────┐            ┌──────────────────────────────┐
│ 1. 禁止编译器优化掉访存   │            │ 1. 上述 volatile 的全部能力    │
│ 2. 强制每次访问都产生     │            │ 2. 内存屏障（禁止 CPU 重排）   │
│    对应的机器指令         │            │ 3. 缓存一致性协议（MESI）       │
│                         │            │ 4. 原子性（RMW 操作的完整性）   │
└─────────────────────────┘            └──────────────────────────────┘

6.3 volatile的正确对比

场景	volatile	原子操作	互斥锁
MMIO 硬件寄存器	✅ 必须	❌ 不必要	❌ 太重
信号处理标志	✅ 必须(sig_atomic_t)	⚠️ 可替代	❌ 信号不安全
多线程标志	❌ 不够	✅ C11 atomic	✅ 也行
多线程计数器	❌ 不够	✅ atomic_fetch_add	✅ 也行
多线程共享结构体	❌ 完全不够	❌ 不够	✅ 必须

7. restrict别名优化

7.1 别名拖慢

疑惑：为什么两个指针可能指向同一块内存会让编译器束手束脚？

论证：

/* 函数签名——编译器必须假设 a 和 b 可能指向同一数组 */
void add_arrays(int *a, const int *b, size_t n) {
    for (size_t i = 0; i < n; i++) {
        a[i] += b[i];           /* 每次读 b[i] 前必须写回 a[i] */
    }
}

汇编（-O2，没有 restrict）：

.L3:
    ldr    r2, [r1, r3, lsl #2]   ; 加载 b[i]
    ldr    r0, [r4, r3, lsl #2]   ; 加载 a[i]
    add    r2, r0, r2             ; a[i] + b[i]
    str    r2, [r4, r3, lsl #2]   ; 存回 a[i]
    add    r3, r3, #1
    cmp    r3, r5
    bne    .L3

为什么需要先 ldr a[i]，再 str 回去，而不是缓存起来一起做？ 因为编译器不知道 a 和 b 是否指向同一块内存——如果 a == b+1，那么 a[i] = a[i] + b[i] 的写操作会改变后续 b[j] 的值。为了安全，每次迭代都必须先写回 a[i]，再重新读 b[i+1]。

7.2 restrict的编译期契约

/* restrict 承诺：在 add_arrays 的生命周期内，
   a 指向的内存区域只通过 a 这个指针访问（b 不会指向同一区域） */
void add_arrays_restrict(int * restrict a,
                         const int * restrict b,
                         size_t n) {
    for (size_t i = 0; i < n; i++) {
        a[i] += b[i];
    }
}

汇编（-O2，有 restrict）→ 开启向量化：

; 编译器现在可以把循环展开，甚至向量化（SIMD）
    vld1.32  {q0}, [r1]!          ; 一次加载 4 个 b 的值到 NEON 寄存器
    vld1.32  {q1}, [r0]           ; 一次加载 4 个 a 的值
    vadd.i32 q0, q1, q0           ; 4 个加法一次完成
    vst1.32  {q0}, [r0]!          ; 一次存回 4 个结果

restrict 是"程序员的承诺"：你向编译器发誓，"这两个指针指向的内存区域不重叠"。编译器基于这个承诺做优化。如果你违反了承诺（实际有重叠），结果是未定义行为。

7.3 memcpy实现的restrict

void *memcpy(void * restrict dest, const void * restrict src, size_t n);

这个签名表达了两个关键语义：

1. restrict dest + restrict src → dest 和 src 不重叠（否则用 memmove）
2. const void * src → src 不会被修改（API 契约）

性能影响——在 glibc 的实现中，memcpy 对大数据块使用 SIMD 指令（一次拷贝 16-32 字节），依赖于 restrict 承诺保证正确性。如果用 memcpy 拷贝重叠区域，结果是未定义的——应该用 memmove。

7.4 restrict误用导致UB

/* ❌ restrict 承诺被打破——UB */
int arr[100];
int * restrict a = arr;
int * restrict b = arr + 1;    /* a 和 b 指向同一数组——打破独占承诺！ */

for (int i = 0; i < 50; i++) {
    a[i] += b[i];                /* UB——编译器假定 a 和 b 不重叠 */
}

/* ✅ 正确——两个完全不同的数组 */
int arr1[100], arr2[100];
int * restrict a = arr1;
int * restrict b = arr2;         /* a 和 b 真正不重叠 */

restrict 的适用场景：

• 数学函数（memcpy、daxpy、矩阵运算）
• 已知输入输出不重叠的 DSP/图像处理循环
• 编译器自带的库函数（sprintf、strcpy）内部使用

8. 限定符模式

8.1 const防御性编程

/* 模式 1：只输入参数——const + 指针 */
ssize_t write_data(int fd, const void *buf, size_t count);
/* buf 只读——调用者不用担心数据被篡改 */

/* 模式 2：只读配置——const + 结构体指针 */
int init_device(const DeviceConfig *cfg);
/* cfg 指向的配置不会被修改 */

/* 模式 3：函数返回值的 const——防止意外赋值 */
const char *get_error_msg(int code) {
    static const char *msgs[] = {"OK", "ERROR", "TIMEOUT"};
    return msgs[code % 3];
}
/* 调用者不能修改返回的字符串——它指向静态存储区 */

/* 模式 4：const 在 API 层面的分层 */
typedef struct {
    int  (*get_value)(const void *self);     /* self 只读 */
    void (*set_value)(void *self, int val);  /* self 可写 */
} Interface;

8.2 volatile在嵌入式驱动

/* 完整的 MMIO 寄存器访问模式 */
typedef struct {
    volatile uint32_t CR;    /* 控制寄存器 */
    volatile uint32_t SR;    /* 状态寄存器 */
    volatile uint32_t DR;    /* 数据寄存器 */
} UART_Regs;

#define UART1  ((UART_Regs *)0x40011000)

/* 发送一个字节 */
void uart_send_byte(char c) {
    while (!(UART1->SR & (1 << 7))) {  /* 等待发送缓冲区空——volatile 保证每读 */
        /* 空转——不能优化掉 */               /* 次循环都重新读 SR 寄存器 */
    }
    UART1->DR = c;                        /* 写入数据——volatile 保证生成写指令 */
}

8.3 restrict的性能敏感区

/* 场景：大量数据的向量加法——图像处理、信号处理 */
void vec_add(float * restrict dst,
             const float * restrict a,
             const float * restrict b,
             size_t n) {
    /* 编译器三个 restrict 承诺下可以：
       1. 向量化循环（SIMD——一次算 4 或 8 个 float）
       2. 预取数据（知道不会冲突）
       3. 软件流水线
    */
    for (size_t i = 0; i < n; i++) {
        dst[i] = a[i] + b[i];
    }
}

性能测试（单精度浮点，1M 元素，Cortex-A53）：

版本	时间	加速比
无 restrict	3.2 ms	1×
有 restrict（自动向量化）	0.9 ms	3.6×
手写 NEON	0.4 ms	8.0×

restrict 不花钱——它只添加一个编译期注解，但能让编译器的自动向量化能力翻倍。

9. 常见误用与反模式

9.1 const的虚假安全感

const int *p = &x;
/* "p 指向 const int"——但这并不意味着 x 不会被改变 */
x = 42;       /* ✅ 通过非 const 路径完全合法 */
(*p) == 42;   /* ✅ p 看到的是最新的值 */

/* const 的真正含义："我不会通过 p 去改它"——不是"它不会被改" */

不要以为有了 const 就可以在多线程环境下不加锁——另一条线程完全可能通过非 const 路径同时修改同一块内存。

9.2 volatile的性能陷阱

/* ❌ 过度使用 volatile——每次访问都到内存，禁用大量优化 */
volatile int counter;
for (int i = 0; i < 1000000; i++) {
    counter++;  /* 每次都是 read-modify-write 到内存——极慢 */
}

/* ✅ 正确的做法——用局部变量做运算，最后写回 */
int local = counter;
for (int i = 0; i < 1000000; i++) {
    local++;
}
counter = local;

9.3 restrict与const混用

/* restrict 可以和 const 组合——常见的函数签名 */
void copy_data(int * restrict dst, const int * restrict src, size_t n);
/*          dst 独占可写            src 独占只读 */

/* 全部三个限定符的组合 */
extern volatile int * const restrict timer_reg;
/* 读法：timer_reg 是 const restrict 指针，指向 volatile int */
/*      - const:      timer_reg 的指向不可改
   - restrict:  timer_reg 独占这个硬件寄存器地址
   - volatile:  指向的寄存器值随时可能被硬件改变 */

10. 综合案例串讲

10.1 案例真相揭晓

回到医疗设备，六个疑问逐条作答：

疑问	答案
① const intp vs intconst p？	第 3.1-3.3：修饰指向内容 vs 修饰指针本身——从右向左读
② const 真正保护什么？	第 4.1-4.2：编译期承诺——通过这个指针不修改（不是物理保护），可以被绕过但产生 UB
③ volatile 的正确用途？	第 5：硬件 MMIO 寄存器、信号处理标志、setjmp 恢复——保证每次访问都生成真实的内存指令
④ 为什么 volatile 不是同步工具？	第 6：只禁止编译器优化，不提供 CPU 内存屏障、缓存一致性或原子性
⑤ restrict 如何加速代码？	第 7.1-7.2：消除别名假设→编译器可以向量化、预取、寄存器缓存
⑥ 三者如何组合？	第 8-9：const volatile（只读硬件寄存器）、const restrict（只读独占输入）

这个设备的完整修复：

/* 修复要点：
   1. volatile 用于硬件寄存器——BP_SENSOR_DATA 已经正确
   2. const 只用于不会被任何路径修改的纯常量
   3. 校准因子如果会被其他线程更新——不能用 const *，改用原子操作
   4. 信号处理标志用 volatile sig_atomic_t——已正确
   5. 读取函数中需要 volatile 的地方加上 volatile
   6. 处理函数中对大数组的操作可加 restrict 提升性能
*/

#include <stdatomic.h>

/* 硬件寄存器——volatile 正确 */
#define BP_SENSOR_DATA  (*(volatile uint32_t *)0x40003800)
#define BP_SENSOR_READY (*(volatile uint32_t *)0x40003804)

/* 校准因子——如果会被运行时更新，用原子操作代替 const */
static atomic_float calib_factor = ATOMIC_VAR_INIT(1.023f);

/* 全局状态——volatile sig_atomic_t 正确 */
static volatile sig_atomic_t emergency_flag = 0;

/* 配置结构体——不再用 const float* 传递可能变化的数据 */
typedef struct {
    float calib;          /* 值拷贝——避免指针别名问题 */
    int   sample_count;
} BPConfig;

/* 信号处理——不变 */
void bp_isr_handler(void) {
    if (BP_SENSOR_READY & 0x01) {
        uint32_t raw = BP_SENSOR_DATA;
        if (raw > 0x80000000) {
            emergency_flag = 1;
        }
    }
}

/* 读取函数修复——添加 volatile 到必要的读取，移除 const 别名风险 */
float read_blood_pressure_fixed(const BPConfig *cfg) {
    float sum = 0.0f;
    float calib = atomic_load(&calib_factor);  /* 原子读取最新校准值 */

    for (int i = 0; i < cfg->sample_count; i++) {
        volatile uint32_t *ready = &BP_SENSOR_READY;
        while (!(*ready & 0x01)) {}  /* volatile——每循环必读 */

        uint32_t raw = BP_SENSOR_DATA;  /* volatile——确保读到真实值 */
        float pressure = (float)raw * calib;
        sum += pressure;
    }

    return sum / cfg->sample_count;
}

修复效果：

• -O2 下读数稳定——不再因为编译器缓存 const* 而产生漂移
• 校准因子通过原子操作保证线程安全
• 硬件寄存器的 volatile 访问不被优化

10.2 限定符实战决策树

你的变量需要：
│
├─ 硬件寄存器（MMIO）？
│     └─ 是 → volatile
│
├─ 函数参数，不想被修改？
│     └─ 是 → const
│
├─ 多线程共享？
│     └─ 是 → atomic / mutex（不是 volatile）
│
├─ 信号处理器中设置？
│     └─ 是 → volatile sig_atomic_t
│
├─ 多个指针可能指向同一数组？
│     └─ 是 → 检查是否可以加 restrict
│
└─ 全局常量，编译期确定？
      └─ 是 → const（可能放 .rodata）

10.3 设计哲学回扣

哲学 1：编译期承诺不是运行期保证——const 的诚实性

const int *p 本质上是对编译器的一句承诺："我不会通过这个指针写"。编译器基于这个承诺做优化（比如缓存值在寄存器中）。如果你用强制转换打破了承诺，编译器不会为你兜底——它已经基于你的承诺做了优化，后果由你承担。const 是一份你和编译器之间的合同，违约方是你——不是编译器。

哲学 2：volatile 的极限——抵制优化不等于同步

volatile 只要求编译器每次访问都生成内存指令——不省略、不合并、不重排。它不涉及 CPU 的乱序执行、多核缓存一致性或原子性。把 volatile 当同步工具用，就像"我不跳过红灯"——它保证你看到红灯，但不保证其他司机也看到。多线程安全需要更重的武器。

哲学 3：restrict 的信任机制——最大的优化来自最强的承诺

restrict 是 C 语言给性能优化留的最强武器——"我承诺这个指针独占这片内存，你（编译器）尽情优化吧"。如果承诺成立，编译器可以向量化、预取、缓存——性能翻倍。如果承诺不成立，UB 的后果是毁灭性的。最强的优化，来自程序员最精准的知识。

哲学 4：组合的力量——限定符是正交的设计维度

const volatile *p 不是一个矛盾体——它精准表达了"硬件只读寄存器"的语义：const 告诉程序员"不要写这个"，volatile 告诉编译器"每次都要重新读"。三个限定符是正交的——const 管 API 契约，volatile 管硬件交互，restrict 管性能优化。正交性 = 组合力量的来源。

10.4 限定符速查

声明	含义	典型场景
const int *p	不能通过 p 改 *p	只读输入参数
int * const p	p 不能改指向	固定迭代器
const int * const p	都不能改	ROM 指针
volatile int *p	每次 *p 必读内存	MMIO 寄存器
const volatile int *p	只读硬件寄存器	状态寄存器
int * restrict p	p 独占该内存	向量化循环参数
volatile sig_atomic_t x	信号安全的标志	信号处理器

限定符自检清单：

1. 一个指针被声明为 const 后，还有非 const 路径可写吗？
2. volatile 是不是被当成了同步工具（应该用 atomic/mutex）？
3. restrict 的承诺真的成立吗——两个指针永远不会重叠？
4. volatile 和 const 可以组合用吗——（只读硬件寄存器）？

---

下一篇：限定符是编译器给我们的三种"模式切换"，下一步进入 07.补码与位运算原理——把整数的二进制表示、位运算的经典技巧从晶体管级别掰开揉碎。