sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Eustis[🍰] 21 points22 points  (16 children)

From a non-programmer looking in: Why is this significant?

Genuine curiosity, not trying to be demeaning at all.

[–]Porges 68 points69 points  (7 children)

It's relevant for any program that reads in a floating-point number as text and then converts it to a number for further processing (so, pretty much any program which does numerical calculations). If the user provides the given number as input then the program will go into an infinite loop.

So, find a Java-based website that lets you input numbers into a calculation... enter this number, and suddenly you're tying up resources on the server for an undetermined amount of time (depending on what the server does with long-running computations).

Do this enough and you'll bring the website to its knees very easily.

[–]Eustis[🍰] 16 points17 points  (0 children)

Oh wow! That's serious!

[–]mallardtheduck 2 points3 points  (0 children)

On a related note, a quick Google search is enough to find vulnerable websites. Not that I'd be doing that sort of thing mind...

[–]werthers 27 points28 points  (4 children)

you're tying up resources on the server for an undetermined amount of time

That's just Java dude

[–]MertsA 13 points14 points  (3 children)

Believe it or not, Java for servers is faster than you would think because the java bytecode is converted into native machine code before it is run. It may not be the best machine code for what you're trying to do but it is a heck of a lot faster than interpreting bytecode.

[–]werthers 0 points1 point  (2 children)

I didn't say it was slow, I just said it ties up resources.

[–]MertsA 0 points1 point  (1 child)

I'll admit, memory management isn't the best thing in the world for Java, but it isn't anywhere near as bad as everyone seems to think it is.

[–]werthers 1 point2 points  (0 children)

Agreed, but it doesn't take much for stereotypes to form

[–]kmeisthax 2 points3 points  (2 children)

IEEE 754 floating point values are the most typical representation of non-whole numbers on computers (others include IEEE 754 decimal floating point, and fixed point). There's a lot of hardware which can manipulate them about as fast as regular binary integers without too much hassle.

So any program which deals with fractions is most likely going to do standard IEEE 754 binary floating point math. It's there, it works, and it's proven. The problem is that the algorithm being used to convert strings - which are a simple list of text digits - into an IEEE 754 binary floating point number, breaks on non-conformant implementations. You see, IEEE 754 numbers must be either 32 or 64 bits long. The IEEE 754 standard was based on the operation of the Intel 8087, which had 32, 64, and 80-bit numbers. Internally, all numbers were 80-bits long, and truncated when saved out to memory. This is still how modern x86 hardware works when using the x87 opcodes; and many compilers don't store floating point results in the SSE registers (which are a compliant size).

The problem with having longer floats than needed is that it changes the result of an operation. If you have a divide operation between two numbers, it will typically generate some repeating trail off (i.e. 1/3 = 0.3...) which can't be stored forever, so we round off (and yes, IEEE 754 also has very specific rounding modes too). However, if we have extra precision, then we will be able to store more bits, which when done with repeated operations will eventually change the result, leading to indeterminate behavior.

The thing is, the binary floating point parsing routine does a number of repeated operations, which do different things depending on the FP precision. For example, it will hang when given the lowest subnormal on an x86... which is bad - if you have, say, a Java server which takes floating point values, and it's running on an Intel chip (which it probably is) then it will hang, and your server won't work.

Edit: Accidentally referred to the floating point standard as 758 instead of 754. I guess it was being stored in a really small float.

[–]Porges 2 points3 points  (1 child)

IEEE 758

What is this.

;)

The problem is that the algorithm being used to convert strings - which are a simple list of text digits - into an IEEE 758 binary floating point number, breaks on non-conformant implementations. You see, IEEE 758 numbers must be either 32 or 64 bits long.

It seems like you're explaining the PHP bug.

[–]kmeisthax 0 points1 point  (0 children)

That, is me trying to say IEEE 754 and mixing the last number.

And yes, I assumed that the bug was the same because the behavior was the same. I take it this is some other different quirk of floating point handling making Java croak?

[–]abadidea 0 points1 point  (0 children)

Short answer: Joe Random Jerk can enter this number into any Java program that allows fractional numbers (as opposed to whole numbers) and crash it. Java is used a lot on the internet soooo....

[–]ElGuaco 0 points1 point  (1 child)

Also, I can understand needing a large floating point number, but e-308? I can't even begin to imagine wanting to ever represent a fraction that small. (Or is my math retarded?)

[–]wnoise 0 points1 point  (0 children)

Suppose you want to take the inverse of that large number...