指针与编译器：语法分析中的指针、抽象语法树（AST）的指针构建、符号表与指针、中间代码生成中的指针

说实话，很多C语言开发者写了几年指针，却从来没想过编译器是怎么理解这些 * 和 & 符号的。我自己早年也有这个盲区——直到有一次在嵌入式项目里遇到一个极其诡异的段错误，追了三天才发现是编译器对指针类型的解析方式和我想的不一样。嗯，从那以后我就决定，搞懂编译器怎么处理指针，比单纯背语法规则有用得多。

语法分析中的指针：编译器如何看懂你的 * 和 &

你写下一行 int *p = &a;，编译器看到的是什么？

说白了，编译器也是逐字逐句读你的代码。它先做词法分析，把 int、*、p、=、&、a、; 这些token拆出来。然后进入语法分析阶段，根据C语言的文法规则，把这些token组装成一棵结构树。

这里有个关键点：* 这个符号在C语言里有多重身份。它可能是乘法运算符，也可能是指针声明符，还可能是解引用操作符。编译器怎么区分？

核心规则：编译器根据上下文位置来判断。在声明语句中，* 紧跟在类型后面，它是指针声明符。在表达式中，如果 * 出现在变量前面，它是解引用操作符。

我在项目中遇到过一种情况：有人写了 int* p, q;，以为 p 和 q 都是指针。结果 q 只是个普通 int。这就是没搞懂编译器怎么解析声明——* 只跟它右边的标识符绑定，不是跟类型绑定。编译器看到的是 int (*p), q;，而不是 (int*) p, q;。

抽象语法树（AST）的指针构建

语法分析完成后，编译器会生成一棵抽象语法树。这棵树里，指针相关的节点怎么表示？

我习惯把AST想象成代码的骨架。每个节点代表一个语法结构，比如声明节点、表达式节点、赋值节点。指针信息就挂在这些节点上。

// 对于 int *p = &a;
// AST 大致结构如下：

DeclarationNode
  ├── type: int
  ├── declarator: PointerDeclarator
  │     ├── base: Identifier("p")
  │     └── pointer_level: 1
  └── initializer: AddressOfNode
        └── operand: Identifier("a")

你看，PointerDeclarator 节点里有个 pointer_level 字段，表示指针的层级。如果是 int **pp，这个值就是2。AST 的构建过程，其实就是把语法分析得到的扁平token流，转换成这种层次化的树形结构。

小技巧：调试编译器时，可以加 -fdump-tree-original 选项（GCC），把AST打印出来看。我经常用这招检查编译器有没有正确理解我的指针声明。

为什么要用树结构？因为树能自然地表达嵌套关系。想想看，int (*fp)(int) 这种函数指针声明，嵌套了好几层。用树来表示，每一层嵌套就是一个子节点，清晰得很。

符号表与指针：类型信息的存储

AST 建好了，接下来编译器要维护一个符号表。符号表说白了就是个字典，记录每个变量名对应的类型、作用域、存储位置等信息。

对于指针变量，符号表里要存什么？

字段 说明 示例（int *p）
name 变量名 "p"
type_kind 类型种类 POINTER_TYPE
base_type 指向的基础类型 INT_TYPE
pointer_depth 指针层级 1
storage_class 存储类别 AUTO / STATIC 等

我曾经在做一个静态分析工具时，发现很多bug都源于符号表里指针类型信息记录不完整。比如 const int *p 和 int * const p，前者是指向常量的指针，后者是常量指针。符号表里如果只记了"这是个指针"，没记const修饰的位置，后面做类型检查就会出错。

注意：符号表里指针的 base_type 必须是完整的类型信息，不能只是个字符串。否则遇到 struct xxx *p 这种前向声明时，编译器没法做类型兼容性检查。

中间代码生成中的指针

到了中间代码生成阶段，编译器要把AST转换成一种更接近机器指令但平台无关的表示。常见的中间表示有三地址码、LLVM IR等。

指针操作在中间代码里怎么体现？

// C 代码
int a = 10;
int *p = &a;
*p = 20;

// 对应的三地址码（示意）
a = 10
p = &a
*p = 20

// 更细化的表示
t1 = &a
p = t1
t2 = *p
*t2 = 20   // 这里其实隐含了两次访存

你想想看，*p = 20 这条语句，在中间代码里实际上分解成了两步：先取 p 的值（得到地址），再往这个地址写20。如果 p 是多级指针，比如 **p = 20，那就需要三次访存。

中间代码生成时，编译器会做一件很重要的事——指针分析。说白了就是静态地推断指针可能指向哪里。比如：

  • p = &a 之后，编译器知道 p 指向 a
  • 如果后面有 q = p，编译器知道 q 也指向 a
  • 但如果遇到 p = &b，那 p 的指向就变了

我在做嵌入式项目时，经常需要手动优化代码。有一次我发现编译器对某个指针变量的优化特别保守，生成的代码里反复从内存读指针值。后来查了一下，是因为指针别名分析（alias analysis）没通过——编译器不确定这个指针会不会被其他变量修改，所以不敢优化。最后我加了 restrict 关键字，告诉编译器这个指针是独占的，代码效率立马提升了30%。

关键认知：编译器对指针的优化能力，很大程度上取决于它能否准确分析指针的指向关系。指向关系越明确，优化空间越大。

SVG：指针在编译器各阶段的变化

指针在编译器各阶段的变化 源代码 int *p = &a; 词法/语法分析 Token → AST 语义分析 符号表构建 中间代码生成 三地址码 / IR 指针相关 • * 和 & 作为 token • 声明 vs 表达式区分 • 指针层级信息 指针相关 • base_type 记录 • pointer_depth • const/volatile 修饰 指针相关 • PointerDeclarator 节点 • AddressOfNode • DereferenceNode 指针分析、别名分析、访存优化

这张图展示了指针从源代码到中间代码的完整旅程。每个阶段都在指针信息上做了不同的处理——语法分析识别指针结构，语义分析记录类型信息，中间代码生成则进行指针分析和优化决策。

说实话，理解了编译器怎么处理指针，你再回头看那些奇怪的指针语法，就不会觉得是玄学了。一切都是编译器按照既定规则一步步解析、构建、转换的结果。我建议你在写复杂指针声明时，试着站在编译器的角度想一想：它看到这个 * 会怎么理解？这样写会不会让AST变得复杂？符号表里能不能准确记录类型信息？

嗯，这些思考习惯，能帮你写出更清晰、更少bug的指针代码。

公众号：蓝海资料掘金营，微信 deep3321

← 上一章 📖 返回目录 下一章 →