在 ARM 与 Intel 上将 float 强制转换为 unsigned char

Question

当我在 Intel 机器上运行以下 C 代码时...

float f = -512;
unsigned char c;

while ( f < 513 )
{
    c = f;
    printf( "%f -> %d\n", f, c );
    f += 64;
}

...输出如下：

-512.000000 -> 0
-448.000000 -> 64
-384.000000 -> 128
-320.000000 -> 192
-256.000000 -> 0
-192.000000 -> 64
-128.000000 -> 128
-64.000000 -> 192
0.000000 -> 0
64.000000 -> 64
128.000000 -> 128
192.000000 -> 192
256.000000 -> 0
320.000000 -> 64
384.000000 -> 128
448.000000 -> 192
512.000000 -> 0

但是，当我在 ARM 设备（在我的例子中是 iPad）上运行相同的代码时，结果完全不同

-512.000000 -> 0
-448.000000 -> 0
-384.000000 -> 0
-320.000000 -> 0
-256.000000 -> 0
-192.000000 -> 0
-128.000000 -> 0
-64.000000 -> 0
0.000000 -> 0
64.000000 -> 64
128.000000 -> 128
192.000000 -> 192
256.000000 -> 0
320.000000 -> 64
384.000000 -> 128
448.000000 -> 192
512.000000 -> 0

：您可以想象，这种差异可能会在跨平台项目中引入可怕的错误。我的问题是：

1. 我是否错误地假设将浮点数强制转换为无符号字符会在所有平台上产生相同的结果？

2. 他可能是编译器问题吗？

3. 有一个优雅的解决方法吗？

Answer 1

C 标准对于您想要做的事情没有非常严格的规则。这是来自 6.3.1 算术操作数节（特别是 6.3.1.4 实数浮点和整数节）的相关段落：

当实浮点类型的有限值转换为_Bool以外的整数类型时，小数部分被丢弃（即值被截断为零） 。如果整数部分的值不能用整数类型表示，则行为未定义。

关于您所询问的确切案例，甚至还有一个更具体的脚注：

实数浮点类型的值转换为无符号类型时，不需要执行整数类型的值转换为无符号类型时执行的余数运算。因此，可移植实浮点值的范围是(−1, Utype_MAX+1)。

您的情况的 UtypeMAX+1 是 256。你的不匹配案例都是负数。截断后，它们仍然为负，并且超出范围 (-1, 256)，因此它们牢牢地处于“未定义行为”区域。即使您展示的一些匹配案例（其中浮点数大于或等于256）也不能保证有效 - 您只是运气好而已。

因此，您的编号问题的答案是：

1. 是的，您错了。
2. 从某种意义上说，这是一个编译器问题，不同的编译器会给出不同的结果，但由于规范允许它们这样做，所以我不会真正将其称为编译器的错误。
3. 这取决于你想做什么 - 如果你能更好地解释这一点，那么社区上的某个人几乎肯定能够帮助你。

Answer 2

我将回答我自己的问题中的 3，但不会将其标记为已接受的答案。技巧似乎是强制转换中的简单转换：

c = (char) f;

使用 (int) 或 (short) 也可以。我仍然有兴趣找出这个问题的原因在哪里：编译器或处理器。

Answer 3

您正在处理的具体问题对我来说看起来像是字节顺序。尝试用 c = *((char *)&f + sizeof(float) - 1); 或类似的内容替换一个或另一个实现，以获取浮点数的最后一个字节，并查看是否它与其他平台的结果匹配。

一般来说，行为取决于处理器的字节顺序、字长和浮点功能，以及编译器如何定位这些功能。 ARM 是双端字节序，因此它可能与 IA 字节顺序匹配，也可能不匹配。似乎也没有一般保证一个 C 实现支持与另一个 C 实现相同的浮点格式： Fixed-浮点类型的大小。

您在生产代码中使用它吗？我会非常努力地研究为什么需要这样做。其中一种类型可能没有按预期使用。解决方法不会很优雅。