赋值期间C ++ NaN字节表示形式的更改 [英] C++ NaN byte representation changes during assignment

问题描述

在尝试将NaN分配给x64处理器上的变量

In trying to assign a NaN to a variable on an x64 processor

*dest = *(float*)&sourceNaN;

其中

unsigned char sourceNaN[] = {00,00, 0xa0, 0x7f};

浮点指令fld和fstp(在反汇编中可见)将0xa0字节更改为0xe0.因此，目标有一个额外的位设置.有人可以解释为什么会这样吗?这是Windows应用程序.

The floating point instructions fld and fstp (seen in the disassembly) change the 0xa0 byte to an 0xe0. Thus the destination has an extra bit set. Can someone explain why this is happening? This is a Windows application.

汇编语言代码:

005C9B9C  mov         eax,dword ptr [ebp+10h]  
005C9B9F  fld         dword ptr [ebp-80h]  
005C9BA2  fstp        dword ptr [eax] 

推荐答案

0x7fa00000是信号NaN("sNaN"). 0x7fe00000是安静的NaN("qNaN").我还没有听说过x86下的这种行为，但是在ARM下，在操作中使用时，sNaNs会转换为相应的qNaNs，同时会引发FP异常(通常被忽略).看来这里正在发生同样的事情.

0x7fa00000 is a signalling NaN ("sNaN"). 0x7fe00000 is a quiet NaN ("qNaN"). I haven't heard of this behavior under x86, but under ARM sNaNs get converted to the corresponding qNaNs when used in operations, alongside raising an FP exception (which is normally ignored). It looks like the same thing is happening here.

好消息是，它们都是NaN.除非您特别依赖信令行为，否则一切都会顺利进行.

The good news is, they're both NaNs. Unless you're specifically relying on the signalling behavior, everything's going right.

这篇关于赋值期间C ++ NaN字节表示形式的更改的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！