这个在实际工作中也遇到过多次。这个属于被动挖坑的一种情况。不只是某一个公司的某一个产品会出这个问题，而是很多产品都可能出这个问题。这个场景由于历史原因，原来的程序是32位，后来慢慢向64位演进，在演进的过程中，某些程序无法满足64位程序里某些数据类型的内存占位，导致的各种不适应：越界，溢出，强制转换错误等等。
比如原来可能创建一个长度为11字符串，就可以将一个4byte的类型的十进制数值转换成字符串。(其中这个问题，可能会被GCC的4.8版本掩盖，只能在8.5这个版本显露出来。)到了64位，这个就不同了，类型所占内存是8byte，这11个字符串的长度就不能满足需求，转换成字符串这个需求。这样就要在做64位程序转换时，需要这个代码找出来，进行适配，修改。
当一个项目代码量非常大的时候，就需要使用自动工具检查，而不能靠人工来找。当然自动检查工具也是人写的，难免有遗漏的情况。当某一段代码有问题，而又没有做适配，就相当于一个坑，或者是不定时炸弹，不知道在未来的哪一个时候会爆出来。
而且要靠大量的回归测试来弥补自动检查工具的不足。