fix(sermux): OwnedPortChunk
leaving port in chunk
#127
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, the behavior of the
OwnedPortChunk::decode
function isincorrect. The returned
chunk
in theOwnedPortChunk
is constructedby allocating a new
Vec
from the input, decoding aPortChunk
fromit, and then shrinking the
Vec
to the size of thechunk
component ofthe returned borrowed
PortChunk
.This does the wrong thing.
Vec::shrink_to
shrinks theVec
from theend, so we are shrinking it down to the first
chunk.len()
bytes.The port number is at the beginning of the
Vec
, rather than the end,so instead of dropping the port number and keeping the data, we are
dropping the last two bytes of the data and producing a buffer that
contains
[port[0], port[1], data[0], ... data[len(data) - 2]]
. Thismeans the data is silently corrupted.
This branch fixes this behavior by instead constructing the owned chunk
using
pc.chunk.to_vec()
. This has the unfortunate consequence ofmeaning that we allocate twice, rather than once, but it means that we
now return the correct data when using
OwnedPortChunk
. Alternatively,we could use
Vec::remove
twice to remove the first two bytes of theVec
, but that's two O(n) operations, which is probably at least asbad as allocating. We could, potentially, change the
OwnedPortChunk::decode
operation to not just callPortChunk::decode
,but that would be more complicated.
Adding a failing test for this is as simple as adding a round-tripping
test for
OwnedPortChunk
as well asPortChunk
, which we didn't havepreviously. I've also changed the round-tripping tests to use
proptest
to generate arbitrary port numbers and chunks to round trip,
because...why not?