lib/qcbor/README.md

7 except sorting of encoded maps)
21 **Focused on C / native data representation** – Careful conversion of
32   description of decoded data item is 56 bytes. Stack use is light and
35   of memory usage making it good for embedded implementations that
38 **Easy decoding of maps** – The "spiffy decode" functions allow
39   fetching map items directly by label. Detection of duplicate map
40   items is automatically performed. This makes decoding of complex
43 **Supports most of RFC 8949** – With some size limits, all data types
48   allocator be set up. Encoding of indefinite length strings is
55   discipline for very safe coding and handling of binary data.
72 alternative to and built on top of QCBORDecode_GetNext(). They do type
77 entered, members can be retrieved by label.  Detection of duplicate
81 implementation as an error check is only needed at the end of the
85 many fewer lines of code. They also tend to parallel the encoding
120 level of abstraction.
123 RFC 8949. The main part missing is sorting of maps when encoding.
124 TinyCBOR implements a smaller part of the standard.
135 doesn't have to check the return code of every call to an encode or
142 (and at some point byte-string labels). This includes detection of
147 QCBOR provides explicit support many of the registered CBOR tags. For
151 Generally, QCBOR supports safe conversion of most CBOR number formats
156 performed with full proper error detection of overflow and underflow.
160 particularly use for CBOR protocols like COSE that make use of
161 byte-string wrapping.  The implementation of these protocols is
190 These eleven files, the contents of the src and inc directories, make
208 project. Hopefully the easy portability of this implementation makes
232 existing CMake environment. The result of the build process is a static library,
273 * Encoding and decoding of basic float types, single and double-precision
274 * Encoding and decoding of half-precision with conversion to/from single
276 * Preferred serialization of floating-point
297 Note that this does not remove use of the types double and float from
298 QCBOR, but it limits QCBOR's use of them to converting the encoded
301 compiler takes care of it on its own.
303 QCBOR uses its own implementation of half-precision float-pointing
322 This saves only a small amount of object code. The primary purpose for
330 QCBOR's shift and mask based implementation of
335 of floating-point to and from integers, big numbers and
340 Roughly 900 bytes are saved, though about half of this
347 headers). This is useful if the compiler options deny the usage of floating
353 Compilers support a number of options that control
361 In particular, `-mfloat-abi=soft`, disables use of
392  From the table above, one can see that the amount of code pulled in
394  main factor is the number of QCBOR functions called and
400  bring in only 1KB of code.
402  Encoding of floating-point brings in a little more code as does
403  encoding of tagged types and encoding of bstr wrapping.
407  Use of the supplied MemPool by calling  QCBORDecode_SetMemPool() to
410  Basic use of spiffy decode to brings in about 3KB. Using more spiffy
414  Finally, use of all of the integer conversion functions will bring in
428  If QCBOR is installed as a shared library, then of course only one
429  copy of the code is in memory no matter how many applications use it.
433 Here's the list of all features that can be disabled to save object
454 Indefinite lengths are a feature of CBOR that makes encoding simpler
456 know the length of a string, map or array when they start encoding
459 device, it is good to prohibit use of indefinite lengths so the
466 To reduce the size of the decoder define
474 QCBOR_DISABLE_UNCOMMON_TAGS disables the decoding of explicit tags for
476 recognition of these from a major type 6 tag.
478 QCBOR_DISABLE_EXP_AND_MANTISSA disables the decoding of decimal
481 QCBOR_DISABLE_TAGS disables all decoding of CBOR tags. If the input has
494  ### Size of spiffy decode
496  When creating a decode implementation, there is a choice of whether
501  the calling code being smaller, but the amount of code brought in
502  from the QCBOR library will be larger. Basic use of spiffy decode
503  brings in about 2KB of object code.  If object code size is not a
508  If code size is a concern, then use of QCBORDecode_GetNext() will
510  protocols. However, if the CBOR protocol is complex then use of
511  spiffy decode may reduce overall code size.  An example of a complex
512  protocol is one that involves decoding a lot of maps or maps that
520 * [t_cose](https://github.com/laurencelundblade/t_cose) implements enough of
524 Specifically it supports signing and verification of the COSE_Sign1 message.
526 * [ctoken](https://github.com/laurencelundblade/ctoken) is an implementation of
555 * Redistributions of source code must retain the above copyright
556 notice, this list of conditions and the following disclaimer.
559 notice, this list of conditions and the following disclaimer in the
562 * Neither the name of the copyright holder nor the names of its
568 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
572 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
574 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
575 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
576 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.