really test decode_varint_slow

[mumbleskates]

The varint::check helper accepts its encoded argument mutably, which means its implementation is at risk of letting decode_varint deplete bytes from its encoded argument before decode_varint_slow is tested. This is the cause for the awkward code from 2021, including <&[u8]>::clone(&encoded). However, this test is expecting success, so the code was forced to work.

The varint_overflow test, however, expects failure. It was not noticed until now that decode_varint_slow(&mut u64_max_plus_one) on line 1687 always attempts to decode an empty slice &[] and fails to decode for that reason, rather than testing what happens whan it attempts to decode an over-max varint.

This changes all the buffers in question to not be declared mutably, and instead reborrows them to clone the slice.

[caspermeijn]

You only change the test, so there is no bug in the production code, that is good to hear. You are improving the test because it doesn't actually test the correct thing.

[caspermeijn]

I suggest improving code readability here. The &* syntax doesn't explain what is going on. I would do something like this to explicitly create a separated buffer. I think the extra allocations are not a problem in test code.

Suggested change

	decode_varint_slow(&mut &*u64_max_plus_one)
	let mut buffer = Bytes::copy_from_slice(u64_max_plus_one);
	decode_varint_slow(&mut buffer).expect_err("slow decoding u64::MAX + 1 succeeded");

[mumbleskates]

I wrote &* here because it is spelled similarly nearby. The explicit spelling of this action is .as_slice(), which I'm happy to do.

[mumbleskates]

Sorry that's not quite right. It's already a &[u8]; this is a reborrow, so i think it's <&[u8]>::clone.

[mumbleskates]

I made every occurrence of &* reborrows explicit; if you would prefer I can scope that down but it seems like an improvement.

[caspermeijn]

I wrote &* here because it is spelled similarly nearby. The explicit spelling of this action is .as_slice(), which I'm happy to do.

Sorry, I was not aware that the other code already uses &* syntax. Your first commit does the correct thing: make the tests uniform.

I made every occurrence of &* reborrows explicit; if you would prefer I can scope that down but it seems like an improvement.

I think the new syntax (as_slice and such) don't convey the intent of the call. What the code is doing is creating a fresh Buf for each call to decode. So I am thinking of words like copy or clone. Maybe a new function like fn decouple(&[u8]) -> impl Buf or something like that. Do you have ideas?

[mumbleskates]

When the data is in a Vec, it does not implement Buf. To get a Buf, we need to get it as a primitive &[u8] slice, which does implement the trait. (From the bytes documentation: "The simplest Buf is a &[u8].")

We can do this either by using the existence of the Deref<Target = [u8]> trait on the vec to re-borrow the value tersely with &*, or you can get it explicitly with Vec::as_slice. In my opinion the more verbose way conveys the intent of the call perfectly, and i believe the general confusion around all of this (including the extistence of the original bug) is evidence that it's needed.

[LucioFranco]

What might make the most sense is to just use the Bytes::from_static and then clone that. But I don't think it matters much. As for &* vs as_slice as_slice is much better imo.

[LucioFranco]

I know there might be some style improvements but none of this affects public code so we can merge this now and do follow ups in other PRs. Thanks!