最近**跨平台移植，小到小型游戏，大到文件系统、GUI以及OS，这里拿文件系统作为例子，主要阐述一个观点：编译器是死的，人是活的！
例 1上图为FatFs文件系统常用子函数，主要功能检查文件系统是否存在。其中"DWORD temp;”为本人额外定义，也就是说后两个if语句中"temp="也是原先没有的。当我完成前面所有移植工作，测试文件系统是否可用时，问题就出来了，挂载磁盘返回正确参数，但打开不了磁盘，测试程序死等，百般纠结，通过各种方法最终锁定问题根结所在，就是后两个if语句无法正确执行，根据以往经验立刻推断问题归咎编译平台不同。
例 2这个问题更为恶劣，文件系统移植完成，确认文件系统可用，并且前一天还在此文件系统上实现各种应用程序，第二天重新编译，发现显示屏显示不对劲，最下边稍微花屏，然后整个显示就乱了套，完全不符合本人的意愿，代码丝毫没有改动，显示却差之**。首先确认故障原因不在硬件，然后，屏蔽所有显示子函数，花屏现象依然存在，真是郁闷。不过，此类问题不是一回两回碰到过，于是，对文件系统翻箱倒柜，确认问题出在上图所示子函数（该函数功能是读磁盘），其中"void *buff'上，传递给此参数的是一个数组名，此数组为
其中"static"是后面加上去的，起初，由显示屏花屏判断问题跟底层显示驱动有关系，于是开干，往底层找，对底层很熟，三下五除二，找出了原因，显示屏显示要在内存开辟缓存，缓存为二维数组，如下图示
花屏必定是buf数组跟缓存数组有叠加区域，为了把这两个区域强行隔开，buf数组加上关键字"static"，问题迎刃而解！
总结：编译器类别纷繁多样，不存在一款万能的编译平台，它只是模拟人类的思维，按照我们预定的规则替我们办事，但往往不能尽如人意，跟我们的思维总会有差距。所以，编译器只是依照预定的规则给我们办事，规矩是死的，人是活的！ |
楼主
标题置顶
标题高亮
