4 ms·

i didn't think much about this, but couldn't we just check whether we have a string "2.2250738585072012e-308" to parse, and then decide, call the builtin functi

by fedd 16y ago

i didn't think much about this, but couldn't we just check whether we have a string "2.2250738585072012e-308" to parse, and then decide, call the builtin function or not. at least, just check the input hash against a hashcode[1] of "2.2250738585072012e-308" and then call either custom function or the native one. normalizing, parseInt, cunstructing a bigDecimal may be a bit more expencive than the native func (don't know for sure) (and did anyone check whether it hangs on French (?) locale where there is a decimal comma, not dot?) [1] two hashcodes, with small and big "E"

mquander 16y ago
Not really, since you can come up with lots of ways to express 2.2250738585072012e-308 as a string: 0.22250738585072012e-307, 0000000.22250738585072012e-307, 0.222507385850720120000000e-307, and so on. As long as it's the same double, it seems like it should trigger the bug in the same fashion.
- fedd 16y ago
  as people wrote that getting this double from integer part and then applying scale doesn't cause problems, i assumed that the problem in parsing that specific string, but not in that particular double value, which can be represented differently