Int parse errors found with fuzzing

[killercup]

I've been spending entirely too much time playing with libfuzzer recently, and this crate was one of my victims.

It pretty quickly found src/helper.rs:10 – as you can imagine, as soon as you write unwrap anywhere, it'll come back to bite fuzz you ;)

• [x] called Result::unwrap() on an Err value: ParseIntError { kind: Empty } with input b"164800."
• [x] called Result::unwrap() on an Err value: ParseIntError { kind: Overflow }' with input b"04:05:06.1226001015632)*450"

See https://gist.github.com/killercup/8dd9ca721fc29cca5b4c8db51bba75b2 for full logs

cf. https://github.com/rust-fuzz/targets/pull/59

[badboy]

We should probably get rid of the unwraps to avoid all further warnings, but both examples turned up different bugs in the parser itself

1. While investigating this, the question about how to handle trailing things comes up again. Should we handle a trailing . (a dot) as .0 or should we handle it as an error?

[badboy]

1 fixed in https://github.com/badboy/iso8601/pull/13/commits/a538ae900e515f0c59195f54348867c9c075987a 2 fixed in https://github.com/badboy/iso8601/pull/13/commits/5e3723b1e46f133010cd77f4958b77506bc126bb

also fixed further bugs