Closed jchia closed 2 years ago
I would say this looks related to #27 except that it should be no-std. This would be similar to what ciborium does with custom Read
and Write
traits. I don't think it would be very hard to do but the code is currently written assuming random access to the buffer (for example deserializing a varint reads twice every byte).
I think this is a duplicate of #46, as serialized and deserialized space are really the same number.
I think both will be addressed (at least partially) by #54.
DeserializeUnexpectedEnd
does not indicate the minimum number of additional bytes needed for deserialization to work. When the user is trying to deserialize values in a streaming way with incremental reading from the source bytes, without this information he will read too few bytes and read more times than really necessary or read too many bytes and waste buffer space.Can there be a way to determine the minimum additional number of bytes needed when deserializing fails due to insufficient bytes, similar to how nom does it?