iOS5 Xcode4.2浮点字节对齐错误？
看一下这段代码：
这是带有 1 字节结构包装的结构定义文件（用于套接字网络）
#pragma pack(1)
typedef struct _TestStruct1 {
double d1;
double d2;
} TestStruct1;
typedef struct _TestStruct2 {
unsigned long v1;
unsigned short v2;
unsigned long v3;
unsigned long value;
TestStruct1 ts1;
} TestStruct2;
#pragma pack()
好的。现在看下面的简单代码：
TestStruct2 wtf;
wtf.v1 = 0;
wtf.v2 = 0;
wtf.v3 = 0;
wtf.value = 4294967295;
wtf.ts1.d1 = 37.785834f;
wtf.ts1.d2 = 37.785834f;
char * cp = (char *)&wtf;
for (int i = 0; i < sizeof(TestStruct2); i++) NSLog(@"[%d] %d", i, (int)cp[i]);
NSLog(@"wtf.value: %lu", wtf.value);
iPhone 5.0 模拟器 XCode 4.2 上的结果：
[0] 0
[1] 0
[2] 0
[3] 0
[4] 0
[5] 0
[6] 0
[7] 0
[8] 0
[9] 0
[10] -1
[11] -1
[12] -1
[13] -1
[14] 0
[15] 0
[16] 0
[17] 64
[18] -106
[19] -28
[20] 66
[21] 64
[22] 0
[23] 0
[24] 0
[25] 64
[26] -106
[27] -28
[28] 66
[29] 64
wtf.value: 4294967295
没有问题。但当涉及到真实设备（iPhone4）时......
[0] 0
[1] 0
[2] 0
[3] 0
[4] 0
[5] 0
[6] 0
[7] 0
[8] 0
[9] 0
[10] -1
[11] -1
[12] 0
[13] 0
[14] 0
[15] 64
[16] -106
[17] -28
[18] 66
[19] 64
[20] 0
[21] 0
[22] 0
[23] 64
[24] -106
[25] -28
[26] 66
[27] 64
[28] 88
[29] 84
wtf.value: 65535
天哪，会发生什么？我将 wtf.value 存储为 4294967295，但在设备上，它更改为 65535。 此问题仅发生在设备上，而不发生在模拟器上。
iOS5 XCode4.2之前从来没有出现过这个问题。
我该如何修复它？请帮我。
Look at this code:
this is struct definition file with 1byte struct packing (for socket networking)
#pragma pack(1)
typedef struct _TestStruct1 {
double d1;
double d2;
} TestStruct1;
typedef struct _TestStruct2 {
unsigned long v1;
unsigned short v2;
unsigned long v3;
unsigned long value;
TestStruct1 ts1;
} TestStruct2;
#pragma pack()
Ok. now see simple code below:
TestStruct2 wtf;
wtf.v1 = 0;
wtf.v2 = 0;
wtf.v3 = 0;
wtf.value = 4294967295;
wtf.ts1.d1 = 37.785834f;
wtf.ts1.d2 = 37.785834f;
char * cp = (char *)&wtf;
for (int i = 0; i < sizeof(TestStruct2); i++) NSLog(@"[%d] %d", i, (int)cp[i]);
NSLog(@"wtf.value: %lu", wtf.value);
result on iphone 5.0 simulator XCode 4.2:
[0] 0
[1] 0
[2] 0
[3] 0
[4] 0
[5] 0
[6] 0
[7] 0
[8] 0
[9] 0
[10] -1
[11] -1
[12] -1
[13] -1
[14] 0
[15] 0
[16] 0
[17] 64
[18] -106
[19] -28
[20] 66
[21] 64
[22] 0
[23] 0
[24] 0
[25] 64
[26] -106
[27] -28
[28] 66
[29] 64
wtf.value: 4294967295
there is no problem. but when it comes to real device (iPhone4)...
[0] 0
[1] 0
[2] 0
[3] 0
[4] 0
[5] 0
[6] 0
[7] 0
[8] 0
[9] 0
[10] -1
[11] -1
[12] 0
[13] 0
[14] 0
[15] 64
[16] -106
[17] -28
[18] 66
[19] 64
[20] 0
[21] 0
[22] 0
[23] 64
[24] -106
[25] -28
[26] 66
[27] 64
[28] 88
[29] 84
wtf.value: 65535
oh my god what happen? I stored wtf.value with 4294967295, but on the device, it changes to 65535.
this problem happens only on device, not on simulator.
This problem never happens before iOS5 XCode4.2.
How can I fix it? Please help me.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我遇到了这样的问题，涉及浮点计算错误，但在 UI 定位代码中。我通过将以下内容添加
到“构建设置”下的“其他 C 标志”选项来修复此问题，仅适用于 armv6 设备（“添加构建设置”>“添加条件设置”）。
我并不假装完全理解这里发生的事情，但是通过添加此构建设置，您将禁用 Thumb 指令集，根据一些（http://wanderingcoder.net/2010/07/19/ought-arm/) 无论如何都不建议用于armv6构建。 Thumb 改变了浮点计算的工作方式。
I had a problem like this, involving floating-point miscalculations but in UI positioning code. I fixed it by adding:
to the "Other C Flags" options under Build Settings, for armv6 devices only ("Add Build Setting" > "Add Conditional Setting").
I don't pretend to understand exactly what's happening here, but by adding this build setting you're disabling the Thumb instruction set, which according to some (http://wanderingcoder.net/2010/07/19/ought-arm/) is not recommended for armv6 builds anyway. Thumb changes the way floating-point calculations work.
根据同一个人（参考克雷格的回答），即我，同一篇文章，在 ARM 上处理未对齐的数据非常糟糕（模拟器是 x86）。我可以理解网络代码中的整数（尽管我宁愿显式序列化），但是应该没有理由出现未对齐的浮点数（在这里，当您存储浮点值时，它似乎会默默地重新对齐到4 字节边界，它会覆盖 wtf.value 的一部分）。您没有通过网络传输原始浮点值，对吧？正确的？
And according to that same person (in reference to Craig's answer), that is, me, in that very same post, handling misaligned data on ARM is very bad (the simulator is x86). I can understand it for integers in network code (though I'd rather explicitly serialize), but there should be no reason to ever have misaligned floating-point numbers (here when you store the floating-point value it seems to be silently realigned to a 4-byte boundary and it overwrites part of wtf.value). You are not transmitting raw floating-point values over the network, right? Right?