4 ms·

> When they do it's often a mistake, like for currency. The most beautiful FP bug I remember was a denial of service in some webservers where by setting the he

> When they do it's often a mistake, like for currency. The most beautiful FP bug I remember was a denial of service in some webservers where by setting the header "Accepted Language: en-gb;q=0.3 en;q=0.8 ..." to a specific value you could send the official Java floating-point parser in an infinite loop (and this affected several Java webservers). So at each webpage request, you were sending one CPU core of the webserver basically busy-looping. Hence crashing the webserver in a few requests at most. Now it'd be heresy if I were to say that maybe, just maybe, had the standards mandated to use 0 to 100 for weighting instead of 0 to 1.0 we could have dodged a whole source of potential issues!? No, no, I realize this is heresy: let's all keep using numbers that cannot even be represented correctly (except as strings), parse those strings into something approximately representing what's written in the string, then make more approximation errors while doing computation with these numbers, propagation errors, epsilon estimation errors, and keep insisting we all could have authored "What every computer scientist should known about floating-point numbers" (which is 80 pages long and, well, approaching a treaty) ; ) /rant off

strictfp 6y ago
Meh, it's not like there can't be a bug in whatever other parsing code a webserver uses. Maybe using a float is overkill in this case, since you're never going to hit more than a hundred languages. But it's at least not setting any limitations.
- mattgreenrocks 6y ago
  The issue is that the representation of floating point numbers imposes additional cognitive burden that the code must handle. How does the web server header parsing code handle positive/negative infinity? How about NaN? NaNs/infs are particularly vicious, as they propagate through computations.
  - rsj_hn 6y ago
    This. Floating point numbers, as they are lossy attempts to discretize continuous data, are more complex and usually non-deterministic. They should never be chosen when a non-lossy representation is available for the problem domain.
  - OneWingedShark 6y ago
    laughs in Ada -- IEEE754/64-bits: Interfaces.IEEE_Float_64 -- And here we strip out non-numeric values. Use Interfaces; Subtype Numeric_Real is IEEE_Float_64 range IEEE_Float_64'Range; Done.
- lostcolony 6y ago
  Based on the OP, this was the official parser for floats. That's a bit more extravagant of a bug. I also would invite you to find a similar instance where a parsing bug for integers crashes the server. Not throws an exception, but falls over in an uncatchable way. I'm not sure I have ever seen one.
- duckerude 6y ago
  No, it is setting limitations, they're just harder to understand and predict. Here's what the RFC says: qvalue = ( "0" [ "." 0*3DIGIT ] ) | ( "1" [ "." 0*3("0") ] ) (https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.9 https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3....) There are 1001 valid values with 1117 representations. Only in practice, Firefox clamps to 2 decimal places, and it used to clamp to 1 decimal place (https://bugzilla.mozilla.org/show_bug.cgi?id=672448 https://bugzilla.mozilla.org/show_bug.cgi?id=672448), and who knows what other software does. And it gets worse: the grandparent suggests there are servers that parse it as floating point. Do they accept q=1e2? If they accept it, are there clients that send it? Do you need to be compatible with those clients?
kevin_thibedeau 6y ago
Don't blame the protocol, blame the language. Nothing prevents the use of fixed point for such numbers. It's just the Java ecosystem and the weakness of languages that use pervasive exceptions to the point that nobody can keep track of them all that is the cause of such issues.
- toast0 6y ago
  > Don't blame the protocol, blame the language. Nothing prevents the use of fixed point for such numbers. I absolutely blame the protocol. Fixed point isn't widely available and used, but integers are. Someone below says protocol spec goes to three digits past the decimal. Using a constrained integer would have allowed the same range of values, but without the complexity of decimal numbers; that's a protocol mistake. In addition to the ease of using floating point numbers to incorrectly represent decimals, there's also fun with formatting, comma vs period, number of digits to report, etc.
throwaway8581 6y ago
There is nothing wrong with the protocol. The protocol has nothing to do with what representation is used by software that speaks the protocol. Software could just as well parse those values as integers. Just drop the decimal point and pad with zeroes. Or use a decimal type (but there is really no need to).
- 8note 6y ago
  The protocol has an obvious implementation choice and some non-obvious alternatives. If the protocol had nothing to do with it, I don't think you'd see the same bug come up in as many implementations
  - deleted 6y ago
    [deleted]
- duckerude 6y ago
  Assigning blame is a bit academic. I think a protocol that used integers instead of decimal point would have led to more correct implementations. So it would be a better protocol.
- quantified 6y ago
  It’s on implementors to be correct. No one said the Java implementation needed to use float or double. Java isn’t the only web server implementation language.
Someone 6y ago
Probably https://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/ https://www.exploringbinary.com/java-hangs-when-converting-2...: “Java — both its runtime and compiler — go into an infinite loop when converting the decimal number 2.2250738585072012e-308 to double-precision binary floating-point. This number is supposed to convert to 0x1p-1022, which is DBL_MIN; instead, Java gets stuck, oscillating between 0x1p-1022 and 0x0.fffffffffffffp-1022, the largest subnormal double-precision floating-point number.”

strictfp 6y ago

Meh, it's not like there can't be a bug in whatever other parsing code a webserver uses. Maybe using a float is overkill in this case, since you're never going to hit more than a hundred languages. But it's at least not setting any limitations.

mattgreenrocks 6y ago
The issue is that the representation of floating point numbers imposes additional cognitive burden that the code must handle. How does the web server header parsing code handle positive/negative infinity? How about NaN? NaNs/infs are particularly vicious, as they propagate through computations.
- rsj_hn 6y ago
  This. Floating point numbers, as they are lossy attempts to discretize continuous data, are more complex and usually non-deterministic. They should never be chosen when a non-lossy representation is available for the problem domain.
- OneWingedShark 6y ago
  laughs in Ada -- IEEE754/64-bits: Interfaces.IEEE_Float_64 -- And here we strip out non-numeric values. Use Interfaces; Subtype Numeric_Real is IEEE_Float_64 range IEEE_Float_64'Range; Done.
lostcolony 6y ago
Based on the OP, this was the official parser for floats. That's a bit more extravagant of a bug. I also would invite you to find a similar instance where a parsing bug for integers crashes the server. Not throws an exception, but falls over in an uncatchable way. I'm not sure I have ever seen one.
duckerude 6y ago
No, it is setting limitations, they're just harder to understand and predict. Here's what the RFC says: qvalue = ( "0" [ "." 0*3DIGIT ] ) | ( "1" [ "." 0*3("0") ] ) (https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.9 https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3....) There are 1001 valid values with 1117 representations. Only in practice, Firefox clamps to 2 decimal places, and it used to clamp to 1 decimal place (https://bugzilla.mozilla.org/show_bug.cgi?id=672448 https://bugzilla.mozilla.org/show_bug.cgi?id=672448), and who knows what other software does. And it gets worse: the grandparent suggests there are servers that parse it as floating point. Do they accept q=1e2? If they accept it, are there clients that send it? Do you need to be compatible with those clients?

kevin_thibedeau 6y ago

Don't blame the protocol, blame the language. Nothing prevents the use of fixed point for such numbers. It's just the Java ecosystem and the weakness of languages that use pervasive exceptions to the point that nobody can keep track of them all that is the cause of such issues.

toast0 6y ago
> Don't blame the protocol, blame the language. Nothing prevents the use of fixed point for such numbers. I absolutely blame the protocol. Fixed point isn't widely available and used, but integers are. Someone below says protocol spec goes to three digits past the decimal. Using a constrained integer would have allowed the same range of values, but without the complexity of decimal numbers; that's a protocol mistake. In addition to the ease of using floating point numbers to incorrectly represent decimals, there's also fun with formatting, comma vs period, number of digits to report, etc.

throwaway8581 6y ago

There is nothing wrong with the protocol. The protocol has nothing to do with what representation is used by software that speaks the protocol. Software could just as well parse those values as integers. Just drop the decimal point and pad with zeroes. Or use a decimal type (but there is really no need to).

8note 6y ago
The protocol has an obvious implementation choice and some non-obvious alternatives. If the protocol had nothing to do with it, I don't think you'd see the same bug come up in as many implementations
- deleted 6y ago
  [deleted]
duckerude 6y ago
Assigning blame is a bit academic. I think a protocol that used integers instead of decimal point would have led to more correct implementations. So it would be a better protocol.
quantified 6y ago
It’s on implementors to be correct. No one said the Java implementation needed to use float or double. Java isn’t the only web server implementation language.

Someone 6y ago

Probably https://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/ https://www.exploringbinary.com/java-hangs-when-converting-2...: “Java — both its runtime and compiler — go into an infinite loop when converting the decimal number 2.2250738585072012e-308 to double-precision binary floating-point. This number is supposed to convert to 0x1p-1022, which is DBL_MIN; instead, Java gets stuck, oscillating between 0x1p-1022 and 0x0.fffffffffffffp-1022, the largest subnormal double-precision floating-point number.”