测试不同平台地址对齐代码
char buf[20];
long *p;
for (int i = 0; i < 20; i++) {
buf = i;
}
for (int i = 0; i < 10; i++) {
p = (long*)((char*)(buf + i));
printf(" %x %x \n",p, *p);
}
X86平台输出,与预期符合
bff84228 03020100
bff84229 04030201
bff8422a 05040302
bff8422b 06050403
bff8422c 07060504
bff8422d 08070605
bff8422e 09080706
bff8422f 0a090807
bff84230 0b0a0908
bff84231 0c0b0a09
arm平台输出,第一列地都正确,地址是对齐的,但里面的值不符合预期,
*p的值不对,"."符号表示这内容是随机值,其余与预期值相同
beaca9ac 03020100 03020100
beaca9ad 00030201 ..030201
beaca9ae 01000302 ....0302
beaca9af 02010003 ......03
beaca9b0 07060504 07060504
beaca9b1 04070605 ..070605
beaca9b2 05040706 ....0706
beaca9b3 06050407 ......07
beaca9b4 0b0a0908 0b0a0908
beaca9b5 080b0a09 ..0b0a09
你的问题就有毛病,ARM平台只有现在的新型处理器架构才支持非对齐数据访问,如果你使用的处理器是旧版本的例如ARM v5之前的就不支持非对齐数据访问,你的问题叫做“arm平台地址虽然对齐”,这是什么意思,既然地址对齐那就不能进行非对齐数据访问,如果非要进行非对齐数据访问那得出的肯定是未知的。
在ARM920t S3C2440
ARM926 MX287
两款处理器上做过测试,他两的核心一样,运行结果都一样
我程序出现BUG,从网络读取数据包,数据包
不限定长度,
【包头标识符 + 长度 + 数据 + 结尾标识】,符规定末尾以0xeeeeffff结尾
原始验证结尾标识代码是这样写
- char buf[n]
- long *p = (long*)(buf + len - 4);
当整个长度是4的倍数时,*p 正好是0xeeeeffff,否则异常。
为了兼容非4倍数的数据包,将指针偏移操作改成malloc
- long size;
- malloc(&size,buf + len - 4, 4);
这样能解决我的问题
那就说明这个ARM9的核不支持非对齐数据访问了,没办法啊这个,向STM32这样比ARM9低端的ARM单片机都还支持非对齐数据访问的,可能是ARM9太old了。
你还是单个字节比较判断吧,哈哈