test(fuzz): cargo-fuzz infrastructure

[weihanglo]

Two things:

Add four new fuzz targets

Each feeds arbitrary data into a parser entry point
and asserts it never panics.

• patch_from_bytes.rs
• patch_from_str.rs
• patch_set_gitdiff.rs
• patch_set_gitdiff_bytes.rs
• patch_set_unidiff.rs
• patch_set_unidiff_bytes.rs

See fuzz/README.md for more.

Add fuzz CI workflow

• PR: 30s smoke test per target
• Daily schedule: 10min per target

See https://rust-fuzz.github.io/book/cargo-fuzz/ci.html

[weihanglo]

Some fuzz result:

Target	Runs	Crashes
patch_from_bytes	1,695,563,708	0
patch_from_str	1,390,604,988	0
patch_set_gitdiff	335,328,861	0
patch_set_gitdiff_bytes	365,712,378	0
patch_set_unidiff	297,150,486	0
patch_set_unidiff_bytes	343,139,344	0

But actually this result was with a change of self.start.saturating_add(self.len). I don't think it is the correct fix but I don't feel like it is worth fixing though.

diffy/src/patch/mod.rs

Lines 392 to 395 in 8fdac0c

	/// Returns the ending line number of the range (exclusive)
	pub fn end(&self) -> usize {
	self.start + self.len
	}

[bmwill]

I don't think it is the correct fix but I don't feel like it is worth fixing though.

Sorry i'm not exactly sure what you mean by this.

Either way happy to get this merged in once its rebased

[weihanglo]

I don't think it is the correct fix but I don't feel like it is worth fixing though.

Sorry i'm not exactly sure what you mean by this.

Either way happy to get this merged in once its rebased

I have two separate fixes for the potential overflow in fn end():

• self.start.saturating_add(self.len) — not good as it lies on overflow
• self.start.check_add(self.len) — return Option so call site need to deal with that. Maybe too much a burden though

[bmwill]

Would be interesting to see the input that led to finding this issue. Seems unlikely that a patch would have usize::MAX lines without some other part of the system giving up first.