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: https://github.com/seanmonstar/httparse/blob/97c7e6e23672df1482930bdcd5ff1eae3dbecf16/src/lib.rs#L843-L867

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.