在g ++ 4.4.3上获得负NaN是这个标准吗？

Question

我在Linux上使用Ubuntu Lucid Lynx获得了g ++ 4.4.3,我得到了一个:

-NAN

结果是.在Hardy Heron上使用g ++ 4.3.1,我得到了所有

楠

这导致我的文本diff回归失败,因为我使用cout来打印这个数值结果.

签名nan的含义是什么,有没有办法告诉编译器无符号的nan是否足够？

Answer 1

行为的改变可能是由于库而不是编译器.glibc肯定会在正确的时间内发生变化 - 从2009-08-23的第2528行ChangeLog.17进入glibc来源:

...
     * stdio-common/printf_fp.c: ISO C expects to print the sign of NaN
     as well.
...

Answer 2

你可以得到一个签署以来的NaN值和值的符号的南岬是由不同的位IEEE754控制(NAN只是通过特殊指数值,从符号位不同的指示).尽管如此,我还不知道会采取什么样的行动.

这可能是产生NaN的正常操作之一可能会造成负面变化(如+0/-0或+Inf/-Inf).但是我会想到nan无论标志如何,NaN都会打印出来.

然而,虽然标准非常详细地规定了数字的处理方式,但它们的打印方式却很奇怪.NaN的维基百科页面列出了以下内容:

nan         NaN         NaN%        NAN         NaNQ
NaNS        qNaN        sNaN        1.#SNAN     1.#QNAN
-1.#IND     -NaN        NaN12345    -sNaN12300

其中一些显示标志和额外的有效载荷.

请注意,我在这里谈论的是IEEE标准.ISO C标准确实指示了有限数量的表单,但是打印的符号和/或有效负载是否依赖于实现.我只能假设库的更高版本改变了他们的行为.

如何在编译器中修复它,我不确定.我只是采取实用的方法并通过类似的方式运行输出文件sed 's/-nan/nan/g'.希望这不会引入其他问题.

此外,您还应该关注允许打印有效负载的表单,但是当测试再次失败时我只会担心.但我会在该sed命令附近的某处发表评论,表明它可能会在未来的某个时间发生.这样,至少跟随你的那个人会明白为什么.