Use safe version of turning u32 into char because the input might
contain surrogates.
This only fixes a symptom and not the underlying issue that surrogates
are not handled at the moment.
If they didn't have enough input data, these two functions were
returning a `Needed` value reflecting the entire expected length, not
the length remaining after the available input.
As a result, a caller that blocks until the specified number of bytes
are available could get stuck waiting forever.
I've fixed the affected tests at the same time as fixing this bug. For
most of them I made sure the tests would detect this error. But for
`tests/overflow.rs`, I deleted the partial input after the length
instead (meaning the tests pass either way), because I don't think it
matters for the purposes of checking if the parsers have an unsigned
overflow.
even if they do not make sense (there's no endianness to care for on a
single byte), importing the new functions is annoying (`use
nom::number::comlete::u8` conflicting, etc), and it will be consistent
with other byte sizes
The trait implementations permit `bitvec` types to be used directly
within the `bytes` parsers, as demonstrated by the `tests/bitstream`
module using `bytes::tag` to process a bitstream.
This unification allows the removal of the `bits` module in favor of
ordinary combinators written to be generic over a consumable input
type.
*breaking change*
this trait allows a custom error type to integrate errors from functions
like `FromStr::from_str`.
This is a breaking change because it modifies the API of `map_res` to
require this trait
*breaking change*
At the beginnng, Needed was supposed to indicate the total number of
bytes needed in the input buffer, and this resulted in complicated
calculations as the parser result bubbled up through previous parsers.
This was changed to indicate only how many additional bytes were needed,
but most of th parsers did not really implement it properly, so this
commit fixes it.
Note: in some cases, like take(&str), where a char can span a varying number
of bytes, we cannot know in advance how many bytes are needed.
For take_until, we could detect that the last few bytes are a prefix of
the tag we are looking for, and indicate how many we need like for
`tag`, but I am not convinced yet that it is worth the effort (and
there's no guarantee that the prefix will be followed by the bytes we
want)
