wps for linux最近的重大bug

zhaohongjian000

同2楼，这诡异的操作目的是什么？

另外，有没有讨论的链接什么的？

zhaohongjian000

bruceteen 发表于 2013-02-22 15:00
在 ILP64 数据模型下 int 就是64bits，你可以Google一下 ILP64

金山的软件显然不跑在这种机器上。基本上我们能见到的环境64位下int都是32位的。

如果val是float，那么valx100就是你说的405EDD2F20000000，不过这种情况下我这里valx100h也不是0.


修改：哦，搞错了把val改成float类型后值valx100值是405EDD2F20000000，和bruceteen说的值不同。

zhaohongjian000

回复 8# shan_ghost


    学习了。另外，x86的机器内部不是80位浮点吗，这么折腾还有意义吗？

leslielg

金山开发人员的新回复

“我们离开了工程环境也模拟不出来。
当时出问题的时候，情况是类似下面这样的。

出错的函数，我们暂且叫A函数，是inline的
另外有一个B函数，调用了A函数，B也是inline的
还有一个C函数，有两处调用B函数，C不是inline的

党我们把B函数去掉inline关键字之后，问题就消失了。
我们再把inline打开后，问题重现。
我们把编译选项-Os去掉后，问题就消失了，加回来就重现了，没有尝试过其他优化选项。

相关代码工程依赖比较多，当我们单纯的模拟上面的情况的时候，也不重现。
~_~”

leslielg

金山开发人员最新回复

“这段代码来自一个非常诡异的逻辑，主要是微软xls存储浮点数的一个逻辑
xls为了存储double类型时节约存储空间，会在某些情况下将某些double存储为4字节。
主要是为判断double的高4字节是不是全是0....”

zhaohongjian000

我把链接给出来：
http://bbs.wps.cn/thread-22359971-4-1.html

shan_ghost

zhaohongjian000 发表于 2013-02-22 15:18

1、判断失误……我直接把bruceteen的数据当小端序内存映像看了。但那个实际是显示值，也就是大端序的。

2、浮点算法很慢。这和位数没关系，只要是浮点都慢。
而利用浮点存储格式进行转换甚至直接计算，就不必使用浮点算法，只需要位操作即可，速度自然就快得多得多了。
当然，根据后面的信息，他们并不是想做这个……

leslielg

但是这个跟他们说的优化的参数，还有是否inline有关系？

hellioncu

浮点数本身不精确，体现在二进制上差异很大，这个不能怪到gcc头上

shan_ghost

leslielg 发表于 2013-02-22 15:36
但是这个跟他们说的优化的参数，还有是否inline有关系？

瞎猜一把： 注意那个double数据的低位字节是全0；当inline时，实际相当于把函数体直接放进调用点，此时就可进行很多上下文相关的优化。

然后，-Os下，可能开启了某个优化，这个优化中有个类似偶之前犯的大小端序错误的bug，这就导致误把低位的全0当作高位截取（和我之前看错的那个性质相同）。

关掉-Os，或者去掉inline，这个优化就无法进行，也就不会引入这种bug了。

不过，如果是这样，那么对其它数据，也应该有结果总是算错这种软bug出现才是。所以感觉这个思路也还是不能自圆其说……