对象表示、指针与别名：C 语言如何看待内存

C 语言的力量来自一个朴素模型：对象占据一段存储，指针保存地址，表达式按类型解释这段存储。 这个模型足够接近机器，也足够危险。 如果只把指针理解成“能访问变量的东西”，就无法解释对齐、别名、对象表示、有效类型和优化器之间的关系。 很多越界、错位访问和权限绕过，根源都是把“字节可见”误解成“任意类型都可读写”。

对象不是变量名

变量名是源码里的标识符。 对象是运行时存储中的一段区域。 对象有大小、对齐、存储期和值。 一个对象可能有名字，也可能没有名字。 malloc 返回的存储在 C 里可以用于创建对象，但这段存储本身不是某个固定类型的变量名。

int x = 42;
int* p = &x;

x 是一个有名字的 int 对象。 p 的值是这个对象的地址。 *p 是通过 int 类型解释这段存储。 类型不是注释，而是编译器推导读写宽度、对齐和别名关系的依据。

对象表示是字节层面的事实

C 标准允许通过 character type 查看对象表示。 这意味着可以把任意对象拆成字节观察。 但观察字节不等于可以用任意类型重新解释它。

#include <stdio.h>

void dump_int(int value) {
  unsigned char* bytes = (unsigned char*)&value;
  for (size_t i = 0; i < sizeof value; ++i) {
    printf("%02x\n", bytes[i]);
  }
}

这段代码读取 int 的对象表示。 它可以用于调试端序、填充和协议序列化。 但如果把这些字节直接当成另一个结构体读，就会进入别名和对齐风险。

端序只解释多字节对象的字节顺序

端序描述多字节整数在内存中的字节排列。 小端机器把低有效字节放在低地址。 大端机器把高有效字节放在低地址。 端序不改变数值语义，只影响对象表示。

uint32_t value = 0x11223344

小端内存：
地址低 -> 44 33 22 11 -> 地址高

大端内存：
地址低 -> 11 22 33 44 -> 地址高

网络协议、文件格式和跨平台缓存必须显式指定字节序。 不要把当前 CPU 的端序泄漏到持久化格式。

对齐是硬件和 ABI 的共同约束

很多类型要求地址按特定边界对齐。 int 可能要求 4 字节对齐。 double 可能要求 8 字节对齐。 结构体成员会插入 padding 来满足对齐。

struct Packet {
  char tag;
  int length;
};

这个结构体通常不是 5 字节。 tag 后面可能有 3 字节 padding。 length 从 4 字节对齐地址开始。 这让 CPU 访问更高效，也满足 ABI 约定。

offset 0: tag
offset 1: padding
offset 2: padding
offset 3: padding
offset 4: length[0]
offset 5: length[1]
offset 6: length[2]
offset 7: length[3]

把网络报文字节流强转成结构体指针，常常同时踩中端序、padding 和对齐问题。

指针值不是普通整数

指针保存可用于定位对象的值。 它可以转换成整数类型再转回，但可移植性有限。 指针算术只在同一个数组对象内有定义。 越过数组末尾一个位置的指针可以形成，但不能解引用。

int a[4] = {1, 2, 3, 4};
int* end = a + 4;

end 是合法的 one-past 指针。 *end 是越界访问。 如果优化器知道数组长度，它可以假设越界不会发生并重排逻辑。

空指针不是地址 0 的语法糖

空指针表示“不指向任何对象或函数”。 实现可以用某种位模式表示它。 源码里的 0、NULL 或 C23 的 nullptr 都可以参与空指针常量语义。 但工程上应该把空指针当作状态，不当作整数地址。

int* p = NULL;
if (p != NULL) {
  *p = 1;
}

空指针检查必须在解引用之前。 解引用之后再检查没有意义，因为程序已经越界了语言承诺。

有效类型决定哪些别名可成立

有效类型是 C 优化的核心边界。 编译器可以假设不同不兼容类型的指针不会指向同一对象。 这就是 strict aliasing 的基础。

float break_aliasing(int* p) {
  float* fp = (float*)p;
  *p = 0x3f800000;
  return *fp;
}

这段代码试图把 int 存储按 float 读取。 它常被用来“解释位模式”，但违反别名规则的风险很高。 优化器可能认为 int* 和 float* 不别名，从而产生意料之外的结果。

安全做法是使用 memcpy 复制对象表示。

#include <string.h>

float bits_to_float(unsigned int bits) {
  float value;
  memcpy(&value, &bits, sizeof value);
  return value;
}

现代编译器通常会把小 memcpy 优化成寄存器移动。 这既表达了字节复制语义，又不破坏别名规则。

character type 是别名规则的观察窗口

char、signed char、unsigned char 可以检查对象表示。 这就是序列化、哈希、调试 dump 的基础。

void wipe(void* p, size_t n) {
  unsigned char* bytes = p;
  for (size_t i = 0; i < n; ++i) {
    bytes[i] = 0;
  }
}

这类函数按字节访问存储。 它适合清理 buffer。 但如果对象包含 padding，padding 字节可能有未指定值。 直接把结构体内存整体写入文件，会把 padding 也写出去，带来信息泄漏和审计风险。

restrict 是给优化器的独占承诺

C 的 restrict 表示在指针生命周期内，通过它访问的对象不会通过其他受限指针访问。 这是手写高性能内存代码的重要工具。 但它不是优化提示，而是程序员承诺。 承诺不成立就是未定义行为。

void saxpy(size_t n, float a,
           const float* restrict x,
           float* restrict y) {
  for (size_t i = 0; i < n; ++i) {
    y[i] = a * x[i] + y[i];
  }
}

如果 x 和 y 实际重叠，优化器仍可按不重叠处理。 因此 restrict 必须只用于边界清楚的底层例程。

结构体布局不能默认等同协议布局

结构体适合表达内存中的对象。 协议适合表达跨系统字节流。 两者相似，但不是同一个抽象。

工程上应该用解析函数把字节流转换成结构体对象。 不要让 packed struct 成为默认协议策略。 packed 可能制造错位访问，性能和可移植性都受影响。

内存复制不是对象复制的万能答案

memcpy 复制对象表示。 对纯 C 结构体常常可行。 但对包含资源句柄、内部指针、同步原语的对象，浅拷贝会复制句柄值，而不是资源所有权。

typedef struct Buffer {
  char* data;
  size_t len;
} Buffer;

复制 Buffer 的字节只会让两个对象指向同一块 data。 如果两个对象都释放它，就会 double-free。 这就是 C 里需要所有权约定的原因。

调试对象表示要保留上下文

查看内存时要同时记录：

• 类型。
• 大小。
• 对齐。
• 字节序。
• 编译器选项。
• 目标架构。
• 是否经过 padding。
• 是否跨越对象生命周期。

clang -std=c23 -g -fsanitize=address,undefined alias.c

ASan 能发现越界和释放后使用。 UBSan 能发现错位访问、非法转换等问题。 但它们不能证明所有别名逻辑正确。 代码审计仍然必须理解有效类型。

工程清单

• 不把任意字节流直接强转成结构体。
• 用 memcpy 做位模式转换。
• 不依赖结构体 padding 内容。
• 对跨平台格式显式指定端序和字段宽度。
• 对 restrict 做调用方契约审计。
• 对公共结构体记录 ABI 大小和对齐。
• 对指针算术限定在数组对象内。
• 解引用前完成空指针检查。
• 对内存 dump 做权限和隐私隔离。
• 在 CI 中启用 ASan/UBSan 路径。

小结

C 的内存模型不是“地址随便转”。 它是一套围绕对象、表示、类型、对齐和别名建立的低层契约。 指针让程序接近机器，也让错误绕过很多保护。 写可靠 C 代码，就是在每一次地址解释之前确认对象是否存在、类型是否匹配、对齐是否满足、生命周期是否仍然有效。