You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: MIGRATION_GUIDE.md
+10Lines changed: 10 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,6 +13,16 @@
13
13
14
14
* A fix was made to the naming of bstr elements with a .size specifier, which might mean that these elements change name in your code when you regenerate.
15
15
16
+
* The fragmented payload API has been completely redesigned to accomodate adding the encoding counterpart.
17
+
The docs have been updated and there's a new section in the README to explain the functionality.
18
+
19
+
* You must now define ZCBOR_FRAGMENTS to access the API
20
+
*`zcbor_*str_decode_fragment()` has been renamed to `zcbor_*str_fragments_start_decode()`
21
+
* After calling `zcbor_*str_fragments_start_decode()`, you must now retrieve the first fragment manually with `zcbor_str_fragment_decode()`, instead of via an argument.
22
+
*`zcbor_next_fragment()` and `zcbor_bstr_next_fragment()` have merged and is now called `zcbor_str_fragment_decode()`.
23
+
It does not take a `prev_fragment` argument, instead, this state is kept internally in the state struct.
24
+
*`zcbor_bstr_start_decode_fragment()` has been renamed to `zcbor_cbor_bstr_fragments_start_decode()` and does not return a fragment.
25
+
To retrieve fragments when decoding a CBOR-encoded bstr, use `zcbor_str_fragment_decode()`
Copy file name to clipboardExpand all lines: README.md
+25Lines changed: 25 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -88,6 +88,31 @@ ZCBOR_STATE_D(decode_state, n, payload, payload_len, elem_count, n_flags);
88
88
ZCBOR_STATE_E(encode_state, n, payload, payload_len, 0);
89
89
```
90
90
91
+
Fragmented payloads
92
+
-------------------
93
+
94
+
zcbor can encode and decode payloads in sections, i.e. the payload can be split into separate buffers/arrays.
95
+
This can be useful e.g. if you send or receive your payload in multiple packets.
96
+
When the current payload section is done, call `zcbor_update_state()` to introduce the next section.
97
+
Note that zcbor does not allow section boundaries to split a zcbor header/value pair.
98
+
This means that the following elements cannot be split between sections:
99
+
100
+
- Numbers and simple values (integers, floats, bools, undefined, nil)
101
+
- Tags
102
+
- Headers of lists, maps, tstrs, and bstrs
103
+
104
+
If your payload is split in an unsupported way, you can get around it by making a small section out of the remaining bytes of one section spliced with the start of the next.
105
+
Another option is to leave a little room at the start of each section buffer, and copy the remaining end of one section into the start of the next buffer.
106
+
8 bytes should be enough for this.
107
+
108
+
Lists and maps can span multiple sections, as long as the individual elements are not split as to break the above rule.
109
+
110
+
String payloads can be split across multiple payload sections, if `ZCBOR_FRAGMENTS` is enabled, and the `*str_fragments_*()` APIs are used. Note that in the zcbor docs, the term "string fragment" is used for fragmented strings, while the term "payload section" is used for fragmented CBOR payloads, as passed to `zcbor_update_state()`. These do not always line up perfectly, particularly at the start and end of fragmented strings.
111
+
112
+
CBOR-encoded bstrs can be nested, and there can also be a non-CBOR-encoded innermost string.
113
+
The current innermost string (CBOR-encoded or otherwise) is called the "current string".
114
+
`zcbor_update_state()` modifies all backups so that outer nested CBOR-encoded strings have updated information about the new section.
0 commit comments