Do not accept sequences with no length information
This is a breaking change.
Deserialize Enum discriminant as Uint
The serializer encodes the variant of an enum as a BARE Uint, so the
deserializer should do the inverse when trying to deserialize a message.
Serde's serialize interface only receives variant indexes as u32,
despite the compiler allowing a cast to virtually any primitive integer
Improve variable-length integer robustness
Move the maximum length check above the left shift, so we don't try and
shift more than 64 bits into the accumulator.
Return serde::de::Errors from the invalid branches of the Uint
deserialization implementation rather than panicking on bogus or
Also clean up a Clippy lint in the Uint serialize implementation, using
the .take(i) iterator adapter rather than a ranged for-loop.
only test u128 when serde's 128-bit integers are enabled
Stop blindly allocating fields based on length
If we allocate and zero the memory for a length-prefixed field up front,
it makes it trivial to DOS the deserializer by sending an enormous
Instead allocate at most one page of memory, growing the Vec as required
to accomodate the data actually available in the incoming buffer.
Switch from u32 to uint for lengths
Add Uint/Int types (variable length)
Clarify some allowed behaviour to allow varint deserialization
Since custom functions can't be used in Deserialize implementations,
we have to use some existing functions in special ways.
Fix char support
Previously, this would call the visitor's u32 functions.
Add i128/u128 support using data<16>
Remove references to enum types
Add a few deserialization tests