Bytes::peek_ahead is unsound

[hkBst]

If n is large enough to cause wrapping then self.cursor.wrapping_add(n) would likely be less than self.start. Either saturating_add is needed, or a test that n < end - cursor.

https://github.com/seanmonstar/httparse/blob/master/src/iter.rs#L44-L55

Edit: actually saturating_add does not (yet?) exist for pointer arithmetic

[seanmonstar]

Hm, that does seem true. I'll just note that a search of the method shows it's only ever used correctly. Actually, it's only used once, to check for the 5th byte after comparing the previous 4. That usage could probably be touched up... Though I recognize that match was very specifically tuned to improve performance...

[hkBst]

Right, there is only a single use as you noted, here:

httparse/src/lib.rs

Lines 843 to 867 in 97c7e6e

	pub fn parse_method<'a>(bytes: &mut Bytes<'a>) -> Result<&'a str> {
	const GET: [u8; 4] = *b"GET ";
	const POST: [u8; 4] = *b"POST";
	match bytes.peek_n::<[u8; 4]>(4) {
	Some(GET) => {
	// SAFETY: matched the ASCII string and boundary checked
	let method = unsafe {
	bytes.advance(4);
	let buf = bytes.slice_skip(1);
	str::from_utf8_unchecked(buf)
	};
	Ok(Status::Complete(method))
	}
	Some(POST) if bytes.peek_ahead(4) == Some(b' ') => {
	// SAFETY: matched the ASCII string and boundary checked
	let method = unsafe {
	bytes.advance(5);
	let buf = bytes.slice_skip(1);
	str::from_utf8_unchecked(buf)
	};
	Ok(Status::Complete(method))
	}
	_ => parse_token(bytes),
	}
	}

and the computed pointer is at most one element past the end of the bytes slice, but that also means that there is no need for wrapping_add instead of add. I've made a PR inlining this function and removing it: #188.