mozilla/rhino

Bugs in number to string conversion

Open

#254 ouverte le 14 nov. 2015

Voir sur GitHub
 (6 commentaires) (0 réactions) (0 assignés)JavaScript (812 forks)batch import
Ecma Incompatibilitybuggood first issue

Métriques du dépôt

Stars
 (3 728 stars)
Métriques de merge PR
 (Merge moyen 6j 16h) (15 PRs mergées en 30 j)

Description

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.

Guide contributeur