mozilla/rhino

Bugs in number to string conversion

開放

#254 建立於 2015年11月14日

 (6 則留言) (0 個反應) (0 位負責人)JavaScript (812 個分叉)batch import
Ecma Incompatibilitybuggood first issue

倉庫指標

星標
 (3,728 顆星)
PR 合併指標
 (平均合併 6天 16小時) (30 天內合併 15 個 PR)

描述

I recently ported the V8 double-conversion package to Java for Nashorn. I've done this previously for Rhino, the code is in the v8dtoa package. Since I did the Rhino port, the code has been pulled into a standalone library and greatly enhanced. There's now code for all three kinds of conversion (shortest, fixed, precision) as well as a Bignum-based fallback implementation, and most of all there's a very good test suite (which may have existed before, but probably as part of the greater V8 test suite).

During the Nashorn port I realized that there probably are some bugs in the Rhino port, mostly subtle ones related to signed operations on longs/ints that should be treated as unsigned. In Nashorn I made use of the new unsigned Long/Integer arithmetic API in JDK8, which is probably not an option for Rhino. Still, the Nashorn code and test suite can probably help in spotting the these issues.

http://hg.openjdk.java.net/jdk9/dev/nashorn/file/53edf7f3f10c/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/doubleconv http://hg.openjdk.java.net/jdk9/dev/nashorn/file/53edf7f3f10c/test/src/jdk/nashorn/internal/runtime/doubleconv/test

I'd be happy to help getting this fixed in Rhino. I don't have the time to do it right now. I hope I'll find some time for it soon, and of course I'd also be happy to assist anybody else willing to tackle it. A good first step would be to run FastDtoaTest against the FastDtoa.java class in Rhino.

貢獻者指南