pub fn parse_f64(s: &[u8]) -> Option<f64>Expand description
Redis’s getLongDoubleFromObject, as far as the difference is observable.
A float argument and a float value are parsed by the same rules, and the
rules are stricter than Rust’s str::parse: no leading or trailing
whitespace at all, and nan is refused where the infinities are not. Redis
refuses NaN because every command that takes a float goes on to store the
result, and a stored NaN compares false against itself forever after.
This lives here for the same reason parse_i64 does. It is not a codec
question, it is the same question the string type asks of a stored value,
and the storage layer cannot reach into the wire layer to ask it.
It also takes hexadecimal, because strtold does and Redis inherits every
bit of that. INCRBYFLOAT on a key holding 0x10 counts from sixteen on a
real server, and INCRBYFLOAT key 0x10 adds sixteen. Nobody designed that
and it is unlikely anyone relies on it, but a client that sends it gets an
answer from Redis and an error from us, and telling a client its value is
not a valid float when the server next door accepts it is the kind of
difference that gets found in production rather than in a test.