Windows下C++指针类型转换越界访问的异常结果咨询

首先得明确：你的这段代码触发了C++标准中的未定义行为（Undefined Behavior）——简单说就是你干了标准不允许的操作，所以程序的运行结果完全依赖具体的编译器、栈内存布局和平台（这里是Windows 10 + CLion），没法用标准规则去严格推导，但我们可以结合你给出的结果和常见的平台行为来解释。

疑问1：为什么修改*pn会改变n的值？ #

先拆解关键操作：

• pn = (int *)&c; 把char类型变量c的地址强转为int*类型，这意味着pn认为自己指向的是一个4字节的int变量，但实际上c只有1字节。
• 当你执行*pn = 0x12345678;时，程序会从c的地址开始，连续写入4字节的数据（Windows上int通常占4字节）。

问题核心在栈内存布局：CLion所用的编译器（不管是MSVC还是MinGW）给main函数变量分配栈空间时，n的内存位置恰好和c后面的某几个字节重叠了。比如假设c的地址是0x0012FFAC，小端序下写入0x12345678会按0x78、0x56、0x34、0x12的顺序存入内存，c后面的0x0012FFAD、0x0012FFAE、0x0012FFAF三个字节会被覆盖，而n刚好存在这个区域，所以它的值被意外修改成了0x123456。

本质上，你通过*pn写入了超出c变量范围的内存，这片内存刚好是n的存储空间——这就是未定义行为的典型表现：完全不可预测的内存干扰。

疑问2：为什么*pn的值是0x6565（十进制25957）？ #

同样源于未定义行为：

• 执行int n = *pn;时，程序会从c的地址开始，连续读取4字节的int数据，但c本身只有1字节是有效的（值为0x65），剩下的3字节都是栈上的未初始化残留数据或其他变量的内容。
• 在你的调试场景中，c后面紧邻的字节恰好也是0x65（可能是栈上残留的垃圾值，或是相邻变量的字节），所以读取到的4字节数据里，低16位就是0x6565（十进制25957）——这就是你看到的结果。

如果换个编译环境或调整变量定义顺序，这个值大概率会变成其他随机数，因为栈上的残留数据是不确定的。

重要提醒 #

这段代码违反了C++的严格别名规则，还存在明显的内存越界访问，属于典型的未定义行为。这类代码绝对不能用于实际开发，它的行为完全不可控，在不同平台、编译器甚至不同编译选项下都会得到不同结果，甚至可能直接崩溃。

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