未使用&运算符初始化数组指针的影响与后果解析

Great question! This gets to the heart of how array names behave in C, and why pointer type compatibility matters. Let's break this down step by step.

First, the correct baseline #

The original code:

int x[5] = {1};
int (*a)[5] = &x;

Here's what's going on:

• x is an array of 5 ints, type int[5].
• &x is a pointer to that entire array, which has the type int (*)[5] — exactly the type that a is declared to be.
• This is fully valid: no compiler warnings, no undefined behavior. Dereferencing a (like (*a)[0]) gives you the array x, and pointer operations like a+1 will skip an entire 5-int array (step size = sizeof(int[5])).

What changes when we remove the &? #

Now we have:

int x[5] = {1};
int (*a)[5] = x; // No & operator

The key issue here is type mismatch, caused by C's array-to-pointer decay. When you use an array name like x in most contexts (including assignment), it automatically converts ("decays") to a pointer to its first element — so x becomes an int* (pointer to a single int), not a pointer to the entire array.

But a is declared as int (*)[5] (pointer to array of 5 ints). These are incompatible pointer types, and that leads to two main problems:

1. Compile-time warnings (or errors) #

Nearly all compilers will flag this as a problem. For example, GCC will output a warning like:

warning: assignment to 'int (*)[5]' from incompatible pointer type 'int *'

If you enable strict compilation flags (like -Werror), this warning becomes a hard error, and your code won't compile at all. The compiler is telling you: "Hey, you're trying to put a square peg into a round hole here."

2. Runtime undefined behavior (if you ignore the warning) #

If you force the code to compile anyway, you're entering the land of undefined behavior — the C standard doesn't specify what happens, so results can be unpredictable, crashy, or seem to work by accident. Let's look at two concrete examples:

Example 1: Dereferencing the pointer

#include <stdio.h>
int main() {
    int x[5] = {1, 2, 3, 4, 5};
    int (*a)[5] = x; // Type mismatch
    
    printf("(*a)[0] = %d\n", (*a)[0]); // Might print 1 (looks okay)
    printf("(*a)[4] = %d\n", (*a)[4]); // Might print 5 (also looks okay)
    return 0;
}

This might seem to work at first glance — because the memory address of x (the array's start) is the same as &x (the address of the entire array). But this is just a coincidence. The compiler is treating a as a pointer to a 5-int array, but a actually holds a pointer to a single int. This is still invalid, and could break in unexpected ways (e.g., if the compiler does optimizations based on the declared type).

Example 2: Pointer arithmetic (where things go wrong)

Pointer arithmetic depends entirely on the pointer's declared type. Let's see:

#include <stdio.h>
int main() {
    int x[5] = {1, 2, 3, 4, 5};
    int y[5] = {6, 7, 8, 9, 10};
    
    // Correct case
    int (*a)[5] = &x;
    printf("a+1 points to: %d\n", (*(a+1))[0]); // Skips entire x array, prints 6 (if y is adjacent)
    
    // Incorrect case
    int (*b)[5] = x;
    printf("b+1 points to: %d\n", (*(b+1))[0]); // Moves sizeof(int[5]) = 20 bytes (assuming 4-byte ints)
    // This jumps past x[4] into unknown memory — could print garbage, crash, or do anything else
    return 0;
}

In the incorrect case, b+1 calculates a new address by adding sizeof(int[5]) (20 bytes) to the original address. But if b were a proper int*, b+1 would only add 4 bytes (to point to x[1]). This mismatch leads to accessing memory outside the array, which is undefined behavior.

The bottom line #

Omitting the & creates a type mismatch between the right-hand side (int*) and left-hand side (int (*)[5]). This triggers compiler warnings, and if you ignore those warnings, you'll get undefined behavior at runtime — which could manifest as wrong values, crashes, or other unpredictable issues. Always match pointer types correctly!

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