-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Errors when decoding large-length bitstrings inside a larger CBOR structure using zcbor_decode as a library #477
Comments
The If you do have such CBOR bstrs, the assumption is that they do not contain any "extra" bytes, so the ZCBOR_ERR_PAYLOAD_NOT_CONSUMED error occurs if you do not decode all bytes of the bstr payload, to prevent you from missing any data. Note that the fragment API is being overhauled in #424. Though, unless your CBOR data is fragmented (split into separate buffers in memory), you don't need to use the fragment API. |
So if the bstr is also encoded as CBOR, it would be used in a similar fashion as the Looking at #424, it looks like the |
If you have a fragmented CBOR payload, you use only
But in all cases when decoding CBOR-encoded bstrs, payload_end will be moved to correspond to the end of the string, so you do not decode outside the string before closing it. It's all handled internally, and does not mean your chunks need to align with the end of the bstr. |
During the creation of a wrapper library, unexpected behavior was observed when decoding large bitstrings. Mainly:
If the end of a bitstring was not aligned with the end of the ZCBOR payload, the decode function would fail with a
ZCBOR_ERR_PAYLOAD_NOT_CONSUMED
error code. This is an issue if bitstring are within a larger ZCBOR structure... Is this intended behavior and I am using the function(s) incorrectly, or might this be an oversight?When breaking up a bitstring decode with
zcbor_bstr_start_decode_fragment
,zcbor_bstr_next_fragment
, andzcbor_bstr_end_decode
, the payload would not properly be consumed, as each "next fragment" call would not advance the payload pointer and instead attempt to increase the size of the payload without reallocation or respect to memory (i.e. would increment payload_end instead of payload in the state object).I fixed/worked around these issues in my local copy of the library by implementing these changes:
The text was updated successfully, but these errors were encountered: