Parsing numbers starting with 0 is not supported

[Shnatsel]

Add the following test to the codebase:

#[test]
fn test_parse_i64_fuzzed() {
    let input = b"02221222122210221223";
    let result = parse::<i64>(input).unwrap();
    assert_eq!(result, 02221222122210221223);
}

Run it with SIMD disabled (with the .cargo/config.toml file deleted) and you'll see that it fails. Meanwhile the standard library parses this number correctly.

This bug was discovered using cargo-fuzz. You can find a guide to it here and the fuzzing setup I used here. I will contribute the fuzzing setup to your repository eventually.

[Shnatsel]

Actually, it fails with SIMD enabled as well. So turning SIMD on/off doesn't make any difference.

[Shnatsel]

I am also getting a similar error when trying to parse 0000000000000000000000000000000000000001

The standard library implementation also handles this one correctly.

[RoDmitry]

Zeroes at the beginning of the input are not supported by the design, and I am not sure if it's needed, because it will work slower.

[Shnatsel]

I see, thanks for clarification.

Parsing numbers with leading zeroes is something people also need to do, and I think this library could do it faster than str::strip_leading_maches('0'). There are ways to quickly count leading decimal zeroes with SIMD: KholdStare/qnd-integer-parsing-experiments#2

[RoDmitry]

Hm, it might be not that slow as I thought. Will think about it, thanks

[RoDmitry]

It works, but with length not more then type's numbers max length 2288368 (starting with 16)

[Shnatsel]

FWIW the standard library parser supports even longer sequences of leading zeroes, so that 000000000000000001 does parse correctly into a u16.

It's up to you whether you choose to support this use case.

[RoDmitry]

I just don't see any use cases. If anybody needs it, write it here, with an explanation of the use case, would be interesting to know.

[RoDmitry]

Done in a separate function atoi_simd::parse_skipped