Improved serialization/deserialization for floating point numbers.

[frewsxcv]

"50." --(deserialize)--> yaml::Number::from(50.0) --(serialize)--> "50" --(deserialize)--> yaml::Number::from(50)

• deserialize/serialize inf/-inf/nan
• always output decimal point for truncated floating points

[killercup]

I assume you found this with rust-fuzz/targets#99? :)

[killercup]

error: strict comparison of f32 or f64
  --> src/ser.rs:76:26
   |
76 |         Ok(Yaml::Real(if v.trunc() == v {
   |                          ^^^^^^^^^^^^^^ help: consider comparing them within some error: `(v.trunc() - v).abs() < error`

[dtolnay]

How about switching to dtoa instead? That way we avoid printing big exponents like 25e200f64 as a bunch of garbage digits.

2499999999999999754368647829910432568018032091847598320736246101108455787066727664225769304644938620168687085525975646159967957760326637205079237977314680335729196571361796923253538665328348131219210240.

[frewsxcv]

@dtolnay one issue with dtoa is that it doesn't handle std::f32::INFINITY correctly. dtoa outputs 1.797693134862316e308 and the current implementation outputs inf., which is also wrong. thoughts?

[dtolnay]

From 10.2.1.4. Floating Point it looks like the correct values would be .inf, -.inf, .nan. We would need to handle those cases before calling into dtoa.

[frewsxcv]

@dtolnay how's this look?

[frewsxcv]

can't compare a nan with a nan, so gotta do the is_nan dance 💃

[dtolnay]

Looks good! I filed #89 to follow up on some odd cases. I don't think trim_left_matches('+') is what we want but there is other sketchy code related to + above it anyway.