Fixes UTF8 output length by accounting for variable header size #1
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.
cb0r
was failing to decode data whose key was >23 bytes. This is because 23 is the largest value which does not include a length prefix, per the cbor spec.Here is an example of the issue:
Note the prefix of the 23-character key is
0x77
, while that of the 24-character key is0x78, 0x18
, where 0x18 indicates the length of 24.Failing to account for this extra byte led to
result->length
being invalid, which led to a decoding failure. Simply capturing this header size results in proper decoding.Note that we only needed to fix this for UTF8 types and while we have smoke-tested a large range of types and sizes, there are some types we do not use so similar issues may be present in other areas of the code.