mozilla/rhino

Bugs in number to string conversion

Open

#254 aberto em 14 de nov. de 2015

Ver no GitHub
 (6 comments) (0 reactions) (0 assignees)JavaScript (812 forks)batch import
Ecma Incompatibilitybuggood first issue

Métricas do repositório

Stars
 (3.728 stars)
Métricas de merge de PR
 (Mesclagem média 6d 16h) (15 fundiu PRs em 30d)

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.

Guia do colaborador