函数ReadFromMemory调用后dest指针地址异常变更问题咨询

这是一个典型的内存越界写入问题，根源完全出在ReadFromMemory函数的实现里，跟dest是否在函数作用域内没关系。咱们一步步拆解：

问题核心：memcpy长度硬编码导致越界 #

你调用ReadFromMemory(temp)时，传入的temp是float类型，在绝大多数系统里它只占用4字节的内存空间。但看函数里的memcpy调用：

memcpy(&var,&const4NextInstruction,0x8);

这里硬写了要复制8字节的数据到temp的内存地址上——这就意味着，除了temp本身的4字节，额外的4字节会被写入到temp相邻的内存区域里。

为什么dest会被影响？ #

在栈上声明的局部变量（dest和temp）通常是连续分配的（具体顺序由编译器决定，但不管是dest在temp之前还是之后，越界的写入都会覆盖到它的内存）。你看到dest变成了0x100000000，这刚好是const4NextInstruction变量的后4字节内容——因为前4字节正确写入了temp，后4字节就“溢”到了旁边的dest指针上，把它的地址给改了。

而你说temp的值是正确的，也刚好印证了这一点：前4字节的复制是符合预期的，问题出在多复制的4字节上。

修复方案 #

把memcpy的长度从硬编码的0x8改成用sizeof(T)来获取模板参数对应类型的实际大小：

memcpy(&var, &const4NextInstruction, sizeof(T));

这样不管传入的是float、int还是其他类型，都会只复制对应类型所需的字节数，彻底避免内存越界的问题。

另外额外提醒：你需要确认const4NextInstruction的类型是否和T匹配，或者是否是你需要的数据源——比如如果const4NextInstruction是64位类型（比如double），当T是float时，复制前4字节是否符合你的业务逻辑，但这部分是功能逻辑问题，当前导致dest被篡改的直接原因已经通过上面的修改解决了。

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