restrict指针赋值语义及假设代码正确性、UB与作用域问题问询

1. Semantics of Assigning a restrict Pointer to a Non-restrict Pointer #

The restrict qualifier is a programmer’s promise to the compiler: for the lifetime of the restrict pointer, any modification to the object it points to must be done through that pointer or a pointer directly derived from it (e.g., y + 0, y + 1, etc.).

When you assign a restrict pointer to a non-restrict pointer (like int *a = y where y is restrict), you’re creating an alternative way to access the same object (or array elements). This doesn’t inherently violate the restrict contract—as long as all modifications to the original object are still done through the restrict pointer or its derivatives (including the non-restrict pointer you created).

The key impact is on compiler optimizations: the compiler can still assume no aliasing for the original restrict pointer’s target, but if the non-restrict pointer is used to access other memory (like y + N where N != 0), the compiler loses the ability to assume those locations don’t alias with other pointers (like x in your code).

2. Analysis of the Provided Code #

Let’s break down the code, including edge cases and scope questions:

Code Recap #

#define N 1 // what if it's 0?
void foo(int *x, int * restrict y) {
    *x = 42;
    *y = 0; // compiler can assume *x is still 42.
    {
        int *a = y + N;
        *a = 123; // compiler can no longer assume *x is 42.
    } // does the new scope matter in this case?
}

Key Observations: #

• When N = 1:

  • The first comment is correct: Since y is restrict, the compiler assumes x does not alias y. Modifying *y has no effect on *x, which remains 42.
  • The second comment is also correct: a = y +1 points to the next integer after y. The restrict qualifier only applies to the object y points to (not the entire array), so the compiler can’t rule out that x points to y+1. Modifying *a means *x might have changed, so the assumption about *x being 42 is invalidated.
  • No undefined behavior (UB) exists here if y points to the first element of an array of at least 2 integers (so y+1 is a valid pointer).

• When N = 0:

  • The second comment is wrong: a = y +0 is equivalent to a = y. Since y is restrict, the compiler still assumes x doesn’t alias y, so modifying *a (which is *y) doesn’t affect *x. The compiler can still safely assume *x is 42.
  • No UB here as long as y points to a valid integer (which is required for *y =0 anyway).

• Does the inner scope matter?
  No, the new scope has no impact on the compiler’s aliasing assumptions. The scope of a only determines where the variable is accessible, but the compiler still tracks the relationship between a and y (and the potential for aliasing with x) regardless of where a is declared. The modification to *a affects the compiler’s assumptions about x regardless of the block it’s in.

• Undefined Behavior Risks:
  UB only occurs if:

  1. The caller passes x that aliases y (violating the restrict promise of y).
  2. y does not point to a sufficient array when N >0 (e.g., N=1 but y points to a single integer, making y+1 an invalid pointer and *a=123 UB).

内容的提问来源于stack exchange，提问作者Dan M.