关于C标准restrict关键字正式定义缺陷的技术咨询

案例1：合理代码被判定为未定义行为（UB） #

以下代码功能是将源数组中的正整数复制到目标数组，并输出最后一个被复制的正整数，p与q从未出现别名：

void positive_intcpy(int * restrict q, const int * restrict p, size_t n) {
  int *qBgn = q;
  const int *pEnd = p + n;
  // sequence point S
  while (p != pEnd && *p>0) *q++ = *p++;
  if (q != qBgn) fprintf(stderr,"Debug: %d.\n",*(q-1)); // undefined behavior!?
}
int main(void) {
  int a[6] = {4,3,2,1,0,-1};
  int b[3];
  positive_intcpy(b,a,3);
  return 0;
}

但按C标准字面分析，q-1表达式被判定为基于restrict指针p，导致访问已修改对象时违反const限定要求，被标记为UB。

案例2：GCC优化下的输出矛盾 #

以下代码中，按标准字面理解并未违反restrict规则，不应存在UB，但GCC在不同优化等级下输出不同结果：-O0输出4，-O3输出3，且优化结果符合实际预期：

int f(int *restrict p, int *restrict q) {
  int *p0=p, *q0=q;
  // sequence point S
  if (p != p0) q++;
  if (q != q0) p++;
  *p = 1;
  *q = 2;
  return *p + *q;
}
int main(void) {
  int x;
  printf("%d\n", f(&x,&x));
  return 0;
}

核心疑问：“based on”的预期含义 #

C标准中restrict的设计初衷是保证指针对其指向对象的唯一访问权，但标准里“based on”的定义过于宽泛，导致一些合理代码被误判。其实际预期含义应该是：
只有当指针的取值直接依赖于另一个restrict指针的当前值，且这种依赖会破坏“唯一访问”的承诺（比如导致对同一对象的交叉访问）时，才会触发restrict的约束。简单来说，标准的字面定义把“基于”的范围拉得过大，而编译器和程序员的实际共识是：仅当两个restrict指针指向重叠对象，且指针操作的依赖关系会打破“唯一访问”的约定时，才会认定违规。

避免误优化的编程建议 #

• 拆分指针依赖逻辑：避免让两个restrict指针的修改操作绑定在一起，比如案例1中，改用独立计数器跟踪复制位置，而非依赖指针偏移：

void positive_intcpy(int * restrict q, const int * restrict p, size_t n) {
  size_t copied = 0;
  const int *pEnd = p + n;
  while (p != pEnd && *p>0) {
    q[copied] = *p++;
    copied++;
  }
  if (copied > 0) fprintf(stderr,"Debug: %d.\n", q[copied-1]);
}

• 明确restrict的适用场景：仅在调用方能保证指针无别名时使用restrict，如果存在别名可能（比如案例2中传同一对象地址），不要给参数加restrict——因为违反restrict的前提（无别名）本身就属于UB，编译器的优化是合理的。
• 用临时变量保存关键状态：如果必须使用指针偏移，提前用非restrict的临时变量保存初始位置或关键偏移量，避免编译器认为访问依赖于restrict指针的当前值。
• 简化restrict指针的操作逻辑：让每个restrict指针的操作逻辑独立，不要产生交叉依赖，减少编译器的优化假设空间。

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