Fix unsoundness of peek_ahead in iter.rs

[hkBst]

This fixes the inadequate safety checks, by checking the index n against the length of the byte array. Then there is no need to use wrapping_add instead of add since we now never point outside the array (since we checked the index against length already).

Potentially, there is some performance impact here, but the benchmarks are not very clear about the direction. Perhaps there is none to speak of?

[seanmonstar]

Checking in Godbolt, it seems like this produces less optimized assembly code. Could we just mark the function unsafe and pass the requirement onto the caller?

[hkBst]

I'd love to do that, but I don't see how it would help:

The single caller lib::parse_method does:

• a safe get for 4 bytes match bytes.peek_n::<[u8; 4]>(4) {
• then wants to look at the 5th byte Some(POST) if bytes.peek_ahead(4) == Some(b' ') => {
• then unsafely advances 5 bytes bytes.advance(5);

So, we need to know that the 5th byte exists, which means we need to check against the length of the Bytes somehow.

[seanmonstar]

Since we already know it had 4 bytes, then using cursor.add(5) is safe, since it's either another byte, or the end of the slice. And the docs for ptr::add() say that vec.as_ptr().add(vec.len()) is always safe (which is one byte off the end.)

[hkBst]

Right, I suppose that allows us to simplify the in-bounds check to just a comparison with bytes.end(), but it would also lead to a baroque safety requirement and make peek_ahead an extremely single-use abstraction. I'll try and whip something up.

[hkBst]

@seanmonstar what do you think of this version?

[seanmonstar]

Perfect! Thanks for keeping up on this <3