C语言char数组与指向char数组的指针的区别：为何对数组取址&看似被忽略？

最核心的结论 #

你观察到的“地址值完全一样”是完全符合C语言规则的，但这绝不意味着&操作在数组上失效了——两个操作返回的地址数值相同，但对应的指针类型完全不同，这才是C语言数组设计的核心细节：

• 当直接在表达式里写数组名（比如test2）时，除非碰到三个例外场景（对数组取&、sizeof操作、字符串字面量初始化数组），否则数组名会自动退化为指向数组首元素的指针。对应你代码里的char test2[32]，直接写test2等价于&test2[0]，类型是char *，指向数组内存块的第一个char元素。
• 当对整个数组执行&操作（也就是你写的&test2）时，取的是整个数组对象的地址，类型是char (*)[32]（就是编译器警告里明确指出的类型），指向的“对象”是整个长度为32的char数组。
• 因为数组在内存里是连续排布的，首元素的起始内存位置，和整个数组块的起始内存位置天生是同一个地址——这就是为什么你打印出来两个值完全相等的原因。

为什么类型错了代码还能跑通？ #

你把类型为char (*)[32]的&test2传给要求char *的strcpy参数，本质是做了一次没有安全检查的隐式类型转换：

• 两个不同类型的指针，底层存的就是一个内存地址的数值。因为两个指针指向的内存起始位置完全重合，strcpy拿到这个地址后，只会按照char *的语义从起始位置开始逐字节拷贝字符串，根本不关心这个地址原本是从哪个类型的指针转过来的。
• 举个直白的类比：你把标着“整盒30支铅笔的外包装”的标签，撕下来贴在第一支铅笔的笔身上递给别人，别人只要拿这个标签上的位置找到那支铅笔，自然就能顺着数完整盒的铅笔——只要位置找对，哪怕标签贴错了，当下的动作也不会出错。

千万别把“能跑”当成“代码没问题” #

这种写法的隐患完全来自于类型的差异：

• 同样是对这两个指针做+1的指针运算，结果天差地别：
  • 对char *类型的test2做+1，只会向后偏移1个字节，指向数组的第2个元素test2[1]
  • 对char (*)[32]类型的&test2做+1，会直接向后偏移整整32个字节，直接跨过整个数组块，指向数组内存区域之后的位置
• 你现在的代码能正常运行，纯粹是因为只把地址值传进了函数，没有用到两个类型在指针偏移上的差异。一旦后续代码基于这个错误的指针类型做运算，立刻会出现难以排查的内存越界、数据错乱问题。
• 编译器弹出的incompatible pointer type警告从来不是多余的提示，它专门用来标记这种“碰巧能跑、实则违反类型规则”的写法，在代码评审阶段必须完全清零，不能靠运行时碰运气。

补充个细节：你代码里用%i格式符打印指针地址的写法本身也是不规范的，指针类型的正确打印格式是%p，用%i打印指针属于C标准定义的未定义行为，只是在你的编译环境里，两个指针的数值刚好能被整数格式正确解析，才让你看到了两个完全相等的整数值。

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