C编译器是否遵循restrict正式定义？指针依赖判定疑问

代码示例 #

extern int A[2];

/* 仅返回传入的p */
extern int *identity(int *p);

int f(int *restrict p)
{
    int *q = identity(p);  /* q成为基于p的指针 */
    int *r = A + (p == q);
    *p = 1;
    *r = 2;
    return *p;
}

疑问点 #

此处指针r是否基于被restrict限定的指针p？根据C标准的定义：

[...] 指针表达式E被称为基于对象P，当且仅当（在执行B过程中、E求值之前的某个序列点）修改P使其指向原指向数组对象的副本，会改变E的值。

其中P是指向类型T的restrict限定指针。

按照这个定义，修改p会改变A + (p == q)的值，因此r应该基于p——尽管r必然指向数组A内部，这有点违反直觉，或许我的理解存在错误。

但GCC和Clang并不这么认为，它们会将最后对p的读取优化为直接return 1;，导致调用f(&A[1])时错误返回1而非2。

请问编译器实现者是否误解了标准？若没有，为何f(&A[1])属于未定义行为？我遗漏了什么？

解答 #

编译器并没有误解标准，问题出在对restrict语义的深层理解以及代码中触发的未定义行为。

1. restrict的核心语义前提 #

restrict的本质是向编译器承诺：在该指针的作用域内，其指向的对象只能通过该指针（或基于该指针的其他指针）被访问或修改。任何通过非restrict指针路径修改该对象的操作，都会直接触发未定义行为。

2. 为什么r不被视为基于p的指针？ #

你对“基于指针”的字面理解没错，但忽略了标准定义的隐含前提：指针表达式E的取值依赖必须是通过p指向的对象或其直接关联的指针关系，而非p本身的数值比较结果。

这里的关键是identity是外部函数——编译器只能依据其原型int *identity(int *p)分析，无法得知它一定会返回p。对于编译器来说，q可能是任意指针，p==q的结果是不可预测的，r可能指向A[0]或A[1]。因此编译器无法证明r的取值依赖于p指向的对象，也就不会将r视为基于p的指针。

3. f(&A[1])的未定义行为根源 #

当调用f(&A[1])时，p指向A[1]。此时如果q确实等于p（正如你注释所说），r会指向A[1]，也就是*p的地址。你通过*r=2修改了*p，但r并非基于p的指针——这直接违反了restrict的承诺：存在非p的路径修改了p指向的对象。

一旦触发未定义行为，编译器就可以自由进行优化，不需要考虑这种场景下的正确行为。所以GCC和Clang会按照“*p在被赋值为1后不会被其他路径修改”的假设，将return *p优化为return 1。

4. 补充说明 #

如果你想让编译器识别q等于p，需要将identity的定义放在当前编译单元内，或者使用编译器扩展（如__attribute__((const))）来告诉编译器该函数的返回值仅依赖于输入参数且无副作用。但即使如此，restrict的语义约束依然要求：所有对*p的修改必须通过p或基于p的指针。

内容的提问来源于stack exchange，提问作者pan