这个BUG是在之前的项目中遇到的，当时着实迷糊了几天，但一直没有时间整理，现在把它重现，并整理在这里，给其它朋友一些参考：

先看下面这段测试的代码：

1. #include <stdio.h>  
2. #include <stdlib.h>  
3. #include <assert.h>  
4. #include <unistd.h>  
5. #include <sys/types.h>  
6. #include <sys/stat.h>  
7. #include <sys/statfs.h>  
8.   
9. typedef struct test_t  
10. {  
11.    char num1;  
12.    int  num2;  
13. }__attribute__((packed))test_t;  
14.   
15. int func1(test_t *p);  
16. int func2(int *p);  
17.   
18. int main()  
19. {  
20.    test_t test;  
21.   
22.    func1(&test);  
23.    printf("%d %d/n",test.num1,test.num2);  
24.   
25.    return 0;   
26. }  
27.   
28. int func1(test_t *p)  
29. {  
30.    p->num1=10;  
31.    func2(&(p->num2));  
32.   
33.    return 0;  
34. }  
35.   
36. int func2(int *p)  
37. {  
38.    *p=100;  
39.      
40.    return 0;  
41. }  

这是当时项目中代码的模拟，其在X86平台上输出结果为:

10,100,

在ARM平台上的输出为：

100，134217728，

初看起来就像是指针指错了地方一样，在当时的项目环境中，围绕指针错误做了N多测试，毫无结果，

最后终于想到ARM平台对32位整形的操作默认开始于4字节对齐的地址，

如果整形值得读写开始于非4字节对齐的地址就必须用特殊的指令进行存取，而项目中的代码就如这里的一样，

因为结构体要经过网络传输，所以都使用了1字节对齐，在调用func1的时候，传入参数为test_t类型的结构体，编译器能够通过结构体定义获知其内部变量num2 的对齐信息，

如果在func1内对num2 赋值不会出现差错（测试如此），而对func2来说，传入的是一个整形指针，编译器会默认将其按照4字节对齐地址进行处理，数据必定出错，而在num2前用char填满4个字节后则一切正常。

当时的解决办法为在func1内部定义临时变量并调用func2。一直以为现代编译器已经足够聪明，看来也不尽然呐。