我们是win32的服务器 然后用的cocos的客户端 cocos编译的win32程序 跟android两个不同平台的程序
然后那创建人物的时候 会下发一个int64 也就是longlong的字段 win32没问题 但是android就会出现崩溃 。。
大神：“win32 跟 arm……字序一样吗？”
那又如何检查自序那 ？
大神：”我能想到的最快最土的办法就是，把一个 int64 看成 char[8]，然后打印出来“
崩溃如图
fatal siganl 7（SIGBUS）at
哦，SIGBUS……
大神
这个可能不是 pack 的问题
大神
pack 也无法保证
大神
如果是 SIGBUS 的话，我理解系统可能希望 sBuf+index-sizeof ( __int64 ) 这个地址是一个对齐在 64 位的地址
如果 sBuf 里全都是 64 位数据的话，问题倒也不大，但是如果你还有 GetInt32，GetChar 之类的接口，不按照 8 字节对齐的协议去修改 index 的话，可能有些 cpu 就受不了了——我知道 MIPS 有这说法，ARM 还真不了解
那只能避免使用int64？
大神
没关系，一般 RISC 都还会有 unaligned 指令集的吧……
大神
没关系，一般 RISC 都还会有 unaligned 指令集的吧……
__int64 GetInt64 ( char* sBuf, int& index, unsigned int nBufferLen )
{
__int64 n;
index += sizeof ( __int64 );
memcpy(&n, sBuf+index-sizeof ( __int64 ), sizeof(__int64));
return n;
}; 虽然没有考虑字序 Byte Order 的问题 这么处理 希望 memcpy 中的指令对操作数的要求可以是 unaligned 的
看了log.txt得出结论 不过异常原因基本上八九不离十了：code 1 (BUS_ADRALN)，我猜 ADRALN 就是 Address Alignment 之类的缩写，肯定是这个出问题了
fault addr 776a2db3 这句很要命，这个地址充其量就对齐在 1 字节上吧，或者说根本没对齐……
大神
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3934.html
你可以抽空看看这个，这是 ARM 编译器对未对齐指针的优化，可能会造成干扰
ps 总之最后按照大神的思路算是把问题解决了 虽然我还是云里雾里的