在ARM与Intel之间将浮动强制转换为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. 假设将浮点数强制转换为unsigned char会在所有平台上产生相同的结果,这是错误的吗？

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. 这取决于你想做什么 - 如果你能更好地解释,SO社区的某个人几乎肯定能够帮助你.