Reject trailing bytes when deserializing from &[u8]

[dtolnay]

In deserialize_from, it makes sense to allow deserializing multiple values from the same io::Read. But in deserialize, I think trailing data should be an error.

I would expect this to be an error rather than ignoring b"x":

extern crate bincode;

fn main() {
    println!("{:?}", bincode::deserialize::<char>(b"1x"));
}

[chrisdew]

@dtolnay Is this issue in response to my question: #192 ?

Does it mean that multiple serialised messages (differing by trailing bytes) can deserialise to the same content?

[dtolnay]

#192 (comment) gives a workaround to detect trailing bytes.

[ZoeyR]

I'm wondering if this is possible to achieve without incurring a performance penalty. The first method that came to mind was to modify the SliceReader struct, but the read methods on this struct may get called multiple times and there is no way to know if this is the last call so that method is out. The only other method that is immediatly obvious to me is to keep track of bytes read during the deserialization and error out at the end if bytes read and buffer length don't match. The issue with this method is that we would have to add code (Quite possibly to the sizelimit structs) to check this, which seems like it would be an unwanted amount of overhead. Especially in the common case of SizeLimit::Infinite

Edit: I've figured out a way to do this but the code ends up being much nicer if we can use pub(restricted). @dtolnay or @TyOverby are there any policies on the minimum Rust version bincode needs to compile on?

[dtolnay]

Thanks for tackling this.

• A constant overhead is fine (i.e. not linear in the number of input bytes).
• Using pub(restricted) is fine. It can easily be replaced with #[doc(hidden)] if someone complains.

[TyOverby]

I'm moving this to post-1.0 because I don't think that it is fundamental to the library and can be added in a backwards compatible way with a config option.

The config option won't even need to be a compile-time reified config option either.