隐藏的问题
当然，也有一些问题不会在一开始就很容易地被发现，例如，在64位程序中，long与指针尺寸更大了，随之也会带来包含它们的结构大小上的增长。结构元素的排列方式决定了结构将占用多大的空间，举例来说，一个包含了int其后跟着一个long的结构，在32位程序中占用8字节，但64位程序在结构的第一个元素上加入了4个字节的填充数据，以使第二个元素在边界上排列得更自然，见图1：
|
图1：32位与64位结构中数据的排列方式 |
为最小化填充数据所带来的影响，可把结构中的数据元素按从大到小重新排列。但是，如果数据元素是通过字节流访问的，还必须调整代码中的逻辑部分，以适应结构中的新的数据排列方式。
在那些重新排列结构数据不起作用，或数据元素是通过字节流访问的情况中，就要小心计算填充数据，我们对此的解决方案是，实现一个帮助函数，在把数据写到字节流之前，从结构中消去多余的填充数据；而由此带来的另一个好处是，在读取数据时就不需要作任何修改了，参见例2：
例2：
| typdef struct demo{ int i; long j; } DEMO; DEMO test; /*pout_raw输出原始数据到一个文件中*/ /*输出结构的每一个元素并避免了填充数据*/ pout_raw ((int) file_unit, (char *) test.i, sizeof (test.i)); pout_raw ((int) file_unit, (char *) test.j, sizeof (test.j)); /*下行包含了填充数据*/ pout_raw ((int) file_unit, (char *) test,sizeof(test)); |
数组问题
64位上的long型数组或结构中的数组，不只是比它们32位的对等体包含更大的数值，而且可包含更多的元素。回头看一下前面用来定义数组边界和分配数组大小的4字节变量，它们可被转换成long。如果为了让64程序获得更好的性能，需决定现存的long数组是否应转换成int类型，请参考http://developers.sun.com/prodtech/cc/articles/ILP32toLP64Issues.html。
。
