61–70 of 70 posts
Earlier quoted context omitted.
Yet not astonishing how the GCC team didn't fix it once, for everyone? PS I am pretty sure Oracle, at least on Sun, used SPARCworks compiler, not GCC, from linking C++ against their libs.
They did fix it in 4.5 by having you to pass -fexcess-precision=standard Which apparently defaults to not being standard compliant.
Earlier quoted context omitted.
Rasmussen's hint would work were the number parsing in Oracle's JDK implemented in in C. Volatile keyword in Java does not guarantee writing to memory and reading it back ( http://java.sun.com/docs/books/jls/third_edition/html/classe... ), but using strictfp as a modifier to the method should cause the usage of strict IEEE 64-bit floating point.
Well, the underlying JVM is written in C (C++ actually) along with a bunch of assembly. I figured this needs to be fixed at the JVM level and as such the fix might very well be a single "volatile" addition like it was for PHP.
The interesting value here (dValue) is double but the method is without strictfp-qualifier and thus allowed to use not-quite IEEE-754 doubles.
Were the problem at JVM level, I would think that many numeric libraries written in Java would not work either and the problem would've been spotted earlier.
Edit: Thought Markdown syntax for links was in use here.
Earlier quoted context omitted.
Well, the underlying JVM is written in C (C++ actually) along with a bunch of assembly. I figured this needs to be fixed at the JVM level and as such the fix might very well be a single "volatile" addition like it was for PHP.
Yeah, the JVM is written in C++ but the problem is in Oracle's JDK written in Java. More specifically, line 1596 in FloatingDecimal.java ( http://www.docjar.com/html/api/sun/misc/FloatingDecimal.java... ) is the only place in the correctionLoop that can cause infinite looping. I do not purport to understand what the ulp-function does but clearly it does produce the denormal number we would want. The interesting value…
Earlier quoted context omitted.
Because JSON can include floating-point numbers. If you pass { foo: 2.2250738585072012e-308 } to any JSON service, I'd expect it to invoke Double.parseDouble(...) as part of its input processing, and trip over the bug. This would probably occur before any type checking of the input, and thus would probably work even for a service which does not expect floating-point inputs.
This is not correct. Think about a service which used PHP's json_decode function. PHP has fixed this bug, so there would be no issue. The problem has nothing to do with JSON. It only affects JSON parsers that run on a JVM.
Earlier quoted context omitted.
So they're not falling over themselves to fix a bug which no one has noticed for 10+ years, and which hardly anyone is going to hit in actual use. Maybe they're spending their time fixing problems which are actually affecting developers.
Any public-facing Java server affected by this bug that accepts floating point numbers from the user as a string can be hung by this bug. This is going to be a big problem.
Earlier quoted context omitted.
Most of internet banking systems in my country run on Java. And most of them can be affected if you know where to put this number.
Yes, but fortunately, there is not much reason why anybody would use double when developing a banking system.
GET / HTTP/1.0
Accept-Language: en;q=2.2250738585072012e-308
If you're running Tomcat and you call getLocale() on that servlet request, you're toast.
Earlier quoted context omitted.
Yes, but fortunately, there is not much reason why anybody would use double when developing a banking system.
They don't have to use it directly. GET / HTTP/1.0 Accept-Language: en;q=2.2250738585072012e-308 If you're running Tomcat and you call getLocale() on that servlet request, you're toast.
"q" is more properly represented natively as an integer between 0 and 1000.
Earlier quoted context omitted.
They don't have to use it directly. GET / HTTP/1.0 Accept-Language: en;q=2.2250738585072012e-308 If you're running Tomcat and you call getLocale() on that servlet request, you're toast.
This is precisely why "q" is defined only to accept three digits after the decimal. It's actually not a floating point number, and anyone who parses it as such is just being lazy. "q" is more properly represented natively as an integer between 0 and 1000.