{"id":13720495,"url":"https://github.com/laurencelundblade/QCBOR","last_synced_at":"2025-05-07T12:31:34.189Z","repository":{"id":38974724,"uuid":"148686626","full_name":"laurencelundblade/QCBOR","owner":"laurencelundblade","description":"Comprehensive, powerful, commercial-quality CBOR encoder/ decoder that is still suited for small devices.","archived":false,"fork":false,"pushed_at":"2024-10-30T03:21:49.000Z","size":2740,"stargazers_count":186,"open_issues_count":21,"forks_count":47,"subscribers_count":11,"default_branch":"master","last_synced_at":"2024-10-30T06:20:47.121Z","etag":null,"topics":["c","cbor","cbor-encoder","cbor-library","iot","portable","rfc-7049","rfc-8949","serialization","serialization-library"],"latest_commit_sha":null,"homepage":"","language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/laurencelundblade.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":"SECURITY.md","support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2018-09-13T19:21:35.000Z","updated_at":"2024-10-28T18:03:41.000Z","dependencies_parsed_at":"2023-12-04T22:24:48.789Z","dependency_job_id":"b8329b35-e023-420f-ac74-64bc67f70b9d","html_url":"https://github.com/laurencelundblade/QCBOR","commit_stats":null,"previous_names":[],"tags_count":9,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/laurencelundblade%2FQCBOR","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/laurencelundblade%2FQCBOR/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/laurencelundblade%2FQCBOR/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/laurencelundblade%2FQCBOR/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/laurencelundblade","download_url":"https://codeload.github.com/laurencelundblade/QCBOR/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":252876411,"owners_count":21818176,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["c","cbor","cbor-encoder","cbor-library","iot","portable","rfc-7049","rfc-8949","serialization","serialization-library"],"created_at":"2024-08-03T01:01:04.481Z","updated_at":"2025-05-07T12:31:29.178Z","avatar_url":"https://github.com/laurencelundblade.png","language":"C","funding_links":[],"categories":["Libraries"],"sub_categories":["Networking \u0026 Protocols"],"readme":"![QCBOR Logo](https://github.com/laurencelundblade/qdv/blob/master/logo.png?raw=true)\n\n**QCBOR** is a powerful, commercial-quality CBOR encoder-decoder that\nimplements these RFCs:\n\n* [RFC8949](https://tools.ietf.org/html/rfc8949) The CBOR Standard. (Nearly everything\nexcept sorting of encoded maps)\n* [RFC7049](https://tools.ietf.org/html/rfc7049) The previous CBOR standard.\nReplaced by RFC 8949.\n* [RFC8742](https://tools.ietf.org/html/rfc8742) CBOR Sequences\n* [RFC8943](https://tools.ietf.org/html/rfc8943) CBOR Dates\n\n## QCBOR Characteristics\n\n**Implemented in C with minimal dependency** – Dependent only\n on C99, \u003cstdint.h\u003e, \u003cstddef.h\u003e, \u003cstdbool.h\u003e and \u003cstring.h\u003e making\n  it highly portable. \u003cmath.h\u003e and \u003cfenv.h\u003e are used too, but their\n  use can disabled. No #ifdefs or compiler options need to be set for\n  QCBOR to run correctly.\n\n**Focused on C / native data representation** – Careful conversion of\n  CBOR data types in to C data types,  handling over and\n  underflow, strict typing and such so the caller doesn't have to\n  worry so much about this and so code using QCBOR passes static\n  analyzers easier.  Simpler code because there is no support for\n  encoding/decoding to/from JSON, pretty printing, diagnostic\n  notation... Only encoding from native C representations and decoding\n  to native C representations is supported.\n\n**Small simple memory model** – Malloc is not needed. The encode\n  context is 176 bytes, decode context is 312 bytes and the\n  description of decoded data item is 56 bytes. Stack use is light and\n  there is no recursion. The caller supplies the memory to hold the\n  encoded CBOR and encode/decode contexts so caller has full control\n  of memory usage making it good for embedded implementations that\n  have to run in small fixed memory.\n\n**Easy decoding of maps** – The \"spiffy decode\" functions allow\n  fetching map items directly by label. Detection of duplicate map\n  items is automatically performed. This makes decoding of complex\n  protocols much simpler, say when compared to TinyCBOR.\n\n**Supports most of RFC 8949** – With some size limits, all data types\n  and formats in the specification are supported. Map sorting is main\n  CBOR feature that is not supported.  The same decoding API supports\n  both definite and indefinite-length map and array decoding. Decoding\n  indefinite length strings is supported but requires a string\n  allocator be set up. Encoding of indefinite length strings is\n  planned, but not yet supported.\n\n**Extensible and general** – Provides a way to handle data types that\n  are not directly supported.\n\n**Secure coding style** – Uses a construct called UsefulBuf as a\n  discipline for very safe coding and handling of binary data.\n\n**Small code size** – In the smallest configuration the object\n  code is less than 4KB on 64-bit x86 CPUs. The design is such that\n  object code for QCBOR APIs not used is not referenced.\n\n**Clear documented public interface** – The public interface is\n  separated from the implementation. It can be put to use without\n  reading the source.\n\n**Comprehensive test suite** – Easy to verify on a new platform or OS\n  with the test suite. The test suite dependencies are minimal and the\n  same as the library's.\n\n## Spiffy Decode\n\nThese are functions to decode particular data types. They are an\nalternative to and built on top of QCBORDecode_GetNext(). They do type\nchecking and in some cases sophisticated type conversion.\n\nSpiffy decode supports easier map and array decoding. A map can be\ndescended into with QCBORDecode_EnterMap(). When a map has been\nentered, members can be retrieved by label.  Detection of duplicate\nmap labels, an error, is automatically performed.\n\nAn internal error state is maintained. This simplifies the decode\nimplementation as an error check is only needed at the end of the\ndecode, rather than on every function.\n\nAn outcome is that decoding implementations are simple and involve\nmany fewer lines of code. They also tend to parallel the encoding\nimplementations as seen in the following example.\n\n     /* Encode */\n     QCBOREncode_Init(\u0026EncodeCtx, Buffer);\n     QCBOREncode_OpenMap(\u0026EncodeCtx);\n     QCBOREncode_AddTextToMap(\u0026EncodeCtx, \"Manufacturer\", pE-\u003eManufacturer);\n     QCBOREncode_AddInt64ToMap(\u0026EncodeCtx, \"Displacement\", pE-\u003euDisplacement);\n     QCBOREncode_AddInt64ToMap(\u0026EncodeCtx, \"Horsepower\", pE-\u003euHorsePower);\n     QCBOREncode_CloseMap(\u0026EncodeCtx);\n     uErr = QCBOREncode_Finish(\u0026EncodeCtx, \u0026EncodedEngine);\n\n     /* Decode */\n     QCBORDecode_Init(\u0026DecodeCtx, EncodedEngine, QCBOR_DECODE_MODE_NORMAL);\n     QCBORDecode_EnterMap(\u0026DecodeCtx);\n     QCBORDecode_GetTextStringInMapSZ(\u0026DecodeCtx, \"Manufacturer\", \u0026(pE-\u003eManufacturer));\n     QCBORDecode_GetInt64InMapSZ(\u0026DecodeCtx, \"Displacement\", \u0026(pE-\u003euDisplacement));\n     QCBORDecode_GetInt64InMapSZ(\u0026DecodeCtx, \"Horsepower\", \u0026(pE-\u003euHorsePower));\n     QCBORDecode_ExitMap(\u0026DecodeCtx);\n     uErr = QCBORDecode_Finish(\u0026DecodeCtx);\n\nThe spiffy decode functions will handle definite and indefinite length\nmaps and arrays without the caller having to do anything. This\nincludes mixed definite and indefinte maps and arrays. (Some work\nremains to support map searching with indefinite length strings.)\n\n## Comparison to TinyCBOR\n\nTinyCBOR is a popular widely used implementation. Like QCBOR,\nit is a solid, well-maintained commercial quality implementation. This\nsection is for folks trying to understand the difference in\nthe approach between QCBOR and TinyCBOR.\n\nTinyCBOR's API is more minimalist and closer to the CBOR\nencoding mechanics than QCBOR's. QCBOR's API is at a somewhat higher\nlevel of abstraction.\n\nQCBOR really does implement just about everything described in\nRFC 8949. The main part missing is sorting of maps when encoding.\nTinyCBOR implements a smaller part of the standard.\n\nNo detailed code size comparison has been made, but in a spot check\nthat encodes and decodes a single integer shows QCBOR about 25%\nlarger.  QCBOR encoding is actually smaller, but QCBOR decoding is\nlarger. This includes the code to call the library, which is about the\nsame for both libraries, and the code linked from the libraries. QCBOR\nis a bit more powerful, so you get value for the extra code brought\nin, especially when decoding more complex protocols.\n\nQCBOR tracks encoding and decoding errors internally so the caller\ndoesn't have to check the return code of every call to an encode or\ndecode function. In many cases the error check is only needed as the\nlast step or an encode or decode. TinyCBOR requires an error check on\neach call.\n\nQCBOR provides a substantial feature that allows searching for data\nitems in a map by label. It works for integer and text string labels\n(and at some point byte-string labels). This includes detection of\nitems with duplicate labels. This makes the code for decoding CBOR\nsimpler, similar to the encoding code and easier to read. TinyCBOR\nsupports search by string, but no integer, nor duplicate detection.\n\nQCBOR provides explicit support many of the registered CBOR tags. For\nexample, QCBOR supports big numbers and decimal fractions including\ntheir conversion to floats, uint64_t and such.\n\nGenerally, QCBOR supports safe conversion of most CBOR number formats\ninto number formats supported in C. For example, a data item can be\nfetched and converted to a C uint64_t whether the input CBOR is an\nunsigned 64-bit integer, signed 64-bit integer, floating-point number,\nbig number, decimal fraction or a big float. The conversion is\nperformed with full proper error detection of overflow and underflow.\n\nQCBOR has a special feature for decoding byte-string wrapped CBOR. It\ntreats this similar to entering an array with one item. This is\nparticularly use for CBOR protocols like COSE that make use of\nbyte-string wrapping.  The implementation of these protocols is\nsimpler and uses less memory.\n\nQCBOR's test suite is written in the same portable C that QCBOR is\nwhere TinyCBOR requires Qt for its test. QCBOR's test suite is\ndesigned to be able to run on small embedded devices the same as\nQCBOR.\n\n## Code Status\n\nThe official current release is version 1.4.1 Changes over the last few\nyears have been only minor bug fixes, minor feature additions and\ndocumentation improvements. QCBOR 1.x is highly stable.\n\nWork on some larger feature additions is ongoing in \"dev\" branch.\nThis includes more explicit support for preferred serialization and\nCDE (CBOR Deterministic Encoding).  It will eventually be release as\nQCBOR 2.x.\n\nQCBOR was originally developed by Qualcomm. It was [open sourced\nthrough CAF](https://source.codeaurora.org/quic/QCBOR/QCBOR/) with a\npermissive Linux license, September 2018 (thanks Qualcomm!).\n\n## Building\n\nThere is a simple makefile for the UNIX style command line binary that\ncompiles everything to run the tests. CMake is also available, please read\nthe \"Building with CMake\" section for more information.\n\nThese eleven files, the contents of the src and inc directories, make\nup the entire implementation.\n\n* inc\n   * UsefulBuf.h\n   * qcbor_private.h\n   * qcbor_common.h\n   * qcbor_encode.h\n   * qcbor_decode.h\n   * qcbor_spiffy_decode.h\n* src\n   * UsefulBuf.c\n   * qcbor_encode.c\n   * qcbor_decode.c\n   * ieee754.h\n   * ieee754.c\n\nFor most use cases you should just be able to add them to your\nproject. Hopefully the easy portability of this implementation makes\nthis work straight away, whatever your development environment is.\n\nThe test directory includes the tests that are nearly as portable as\nthe main implementation.  If your development environment doesn't\nsupport UNIX style command line and make, you should be able to make a\nsimple project and add the test files to it.  Then just call\nRunTests() to invoke them all.\n\nWhile this code will run fine without configuration, there are several\nC pre processor macros that can be #defined in order to:\n\n * use a more efficient implementation\n * to reduce code size\n * to improve performance (a little)\n * remove features to reduce code size\n\nSee the comment sections on \"Configuration\" in inc/UsefulBuf.h and\nthe pre processor defines that start with QCBOR_DISABLE_XXX.\n\n### Building with CMake\n\nCMake can also be used to build QCBOR and the test application. Having the root\n`CMakeLists.txt` file, QCBOR can be easily integrated with your project's\nexisting CMake environment. The result of the build process is a static library,\nto build a shared library instead you must add the\n`-DBUILD_SHARED_LIBS=ON` option at the CMake configuration step.\nThe tests can be built into a simple command line application to run them as it\nwas mentioned before; or it can be built as a library to be integrated with your\ndevelopment environment.\nThe `BUILD_QCBOR_TEST` CMake option can be used for building the tests, it can\nhave three values: `APP`, `LIB` or `OFF` (default, test are not included in the\nbuild).\n\nBuilding the QCBOR library:\n\n```bash\ncd \u003cQCBOR_base_folder\u003e\n# Configuring the project and generating a native build system\ncmake -S . -B \u003cbuild_folder\u003e\n# Building the project\ncmake --build \u003cbuild_folder\u003e\n```\n\nBuilding and running the QCBOR test app:\n```bash\ncd \u003cQCBOR_base_folder\u003e\n# Configuring the project and generating a native build system\ncmake -S . -B \u003cbuild_folder\u003e -DBUILD_QCBOR_TEST=APP\n# Building the project\ncmake --build \u003cbuild_folder\u003e\n# Running the test app\n.\u003cbuild_folder\u003e/test/qcbortest\n```\n\nTo enable all the compiler warnings that are used in the QCBOR release process\nyou can use the `BUILD_QCBOR_WARN` option at the CMake configuration step:\n```bash\ncmake -S . -B \u003cbuild_folder\u003e -DBUILD_QCBOR_WARN=ON\n```\n\n### Floating Point Support \u0026 Configuration\n\nBy default, all QCBOR floating-point features are enabled:\n\n* Encoding and decoding of basic float types, single and double-precision\n* Encoding and decoding of half-precision with conversion to/from single\n  and double-precision\n* Preferred serialization of floating-point\n* Floating point dates\n* Methods that can convert big numbers, decimal fractions and other numbers\n  to/from floating-point\n\nIf full floating-point is not needed, the following #defines can be\nused to reduce object code size and dependency.\n\nSee discussion in qcbor_encode.h for other details.\n\n#### #define QCBOR_DISABLE_FLOAT_HW_USE\n\nThis removes dependency on:\n\n* Floating-point hardware and floating-point instructions\n* `\u003cmath.h\u003e` and `\u003cfenv.h\u003e`\n* The math library (libm, -lm)\n\nFor most limited environments, this removes enough floating-point\ndependencies to be able to compile and run QCBOR.\n\nNote that this does not remove use of the types double and float from\nQCBOR, but it limits QCBOR's use of them to converting the encoded\nbyte stream to them and copying them. Converting and copying them\nusually don't require any hardware, libraries or includes. The C\ncompiler takes care of it on its own.\n\nQCBOR uses its own implementation of half-precision float-pointing\nthat doesn't depend on math libraries. It uses masks and shifts\ninstead. Thus, even with this define, half-precision encoding and\ndecoding works.\n\nWhen this is defined, the QCBOR functionality lost is minimal and only\nfor decoding:\n\n* Decoding floating-point format dates are not handled\n* There is no conversion between floats and integers when decoding. For\n  example, QCBORDecode_GetUInt64ConvertAll() will be unable to convert\n  to and from float-point.\n* Floats will be unconverted to double when decoding.\n\nNo interfaces are disabled or removed with this define.  If input that\nrequires floating-point conversion or functions are called that\nrequest floating-point conversion, an error code like\n`QCBOR_ERR_HW_FLOAT_DISABLED` will be returned.\n\nThis saves only a small amount of object code. The primary purpose for\ndefining this is to remove dependency on floating point hardware and\nlibraries.\n\n#### #define QCBOR_DISABLE_PREFERRED_FLOAT\n\nThis eliminates support for half-precision\nand CBOR preferred serialization by disabling\nQCBOR's shift and mask based implementation of\nhalf-precision floating-point.\n\nWith this defined, single and double-precision floating-point\nnumbers can still be encoded and decoded. Conversion\nof floating-point to and from integers, big numbers and\nsuch is also supported. Floating-point dates are still\nsupported.\n\nThe primary reason to define this is to save object code.\nRoughly 900 bytes are saved, though about half of this\ncan be saved just by not calling any functions that\nencode floating-point numbers.\n\n#### #define USEFULBUF_DISABLE_ALL_FLOAT\n\nThis eliminates floating point support completely (along with related function\nheaders). This is useful if the compiler options deny the usage of floating\npoint operations completely, and the usage soft floating point ABI is not\npossible.\n\n#### Compiler options\n\nCompilers support a number of options that control\nwhich float-point related code is generated. For example,\nit is usually possible to give options to the compiler to avoid all\nfloating-point hardware and instructions, to use software\nand replacement libraries instead. These are usually\nbigger and slower, but these options may still be useful\nin getting QCBOR to run in some environments in\ncombination with `QCBOR_DISABLE_FLOAT_HW_USE`.\nIn particular, `-mfloat-abi=soft`, disables use of\n hardware instructions for the float and double\n types in C for some architectures.\n\n#### CMake options\n\nIf you are using CMake, it can also be used to configure the floating-point\nsupport. These options can be enabled by adding them to the CMake configuration\nstep and setting their value to 'ON' (True). The following table shows the\navailable options and the associated #defines.\n\n    | CMake option                      | #define                       |\n    |-----------------------------------|-------------------------------|\n    | QCBOR_OPT_DISABLE_FLOAT_HW_USE    | QCBOR_DISABLE_FLOAT_HW_USE    |\n    | QCBOR_OPT_DISABLE_FLOAT_PREFERRED | QCBOR_DISABLE_PREFERRED_FLOAT |\n    | QCBOR_OPT_DISABLE_FLOAT_ALL       | USEFULBUF_DISABLE_ALL_FLOAT   |\n\n## Code Size\n\nThese are approximate sizes on a 64-bit x86 CPU with the -Os optimization.\nAll QCBOR_DISABLE_XXX are set and compiler stack frame checking is disabled\nfor smallest but not for largest. Smallest is the library functions for a\nprotocol with strings, integers, arrays, maps and Booleans, but not floats\nand standard tag types.\n\n    |               | smallest | largest |\n    |---------------|----------|---------|\n    | encode only   |      850 |    2200 |\n    | decode only   |     1550 |   13300 |\n    | combined      |     2500 |   15500 |\n\n From the table above, one can see that the amount of code pulled in\n from the QCBOR library varies a lot, ranging from 1KB to 15KB.  The\n main factor is the number of QCBOR functions called and\n which ones they are. QCBOR minimizes internal\n interdependency so only code necessary for the called functions is\n brought in.\n\n Encoding is simpler and smaller. An encode-only implementation may\n bring in only 1KB of code.\n\n Encoding of floating-point brings in a little more code as does\n encoding of tagged types and encoding of bstr wrapping.\n\n Basic decoding using QCBORDecode_GetNext() brings in 3KB.\n\n Use of the supplied MemPool by calling  QCBORDecode_SetMemPool() to\n setup to decode indefinite-length strings adds 0.5KB.\n\n Basic use of spiffy decode to brings in about 3KB. Using more spiffy\n decode functions, such as those for tagged types bstr wrapping brings\n in more code.\n\n Finally, use of all of the integer conversion functions will bring in\n about 5KB, though you can use the simpler ones like\n QCBORDecode_GetInt64() without bringing in very much code.\n\n In addition to using fewer QCBOR functions, the following are some\n ways to make the code smaller.\n\n The gcc compiler output is usually smaller than llvm because stack\n guards are off by default (be sure you actually have gcc and not llvm\n installed to be invoked by the gcc command). You can also turn off\n stack gaurds with llvm. It is safe to turn off stack gaurds with this\n code because Usefulbuf provides similar defenses and this code was\n carefully written to be defensive.\n\n If QCBOR is installed as a shared library, then of course only one\n copy of the code is in memory no matter how many applications use it.\n\n### Disabling Features\n\nHere's the list of all features that can be disabled to save object\ncode. The amount saved is an approximation.\n\n    | #define                                 | Saves |\n    | ----------------------------------------| ------|\n    | QCBOR_DISABLE_ENCODE_USAGE_GUARDS       |   150 |\n    | QCBOR_DISABLE_INDEFINITE_LENGTH_STRINGS |   400 |\n    | QCBOR_DISABLE_INDEFINITE_LENGTH_ARRAYS  |   200 |\n    | QCBOR_DISABLE_UNCOMMON_TAGS             |   100 |\n    | QCBOR_DISABLE_EXP_AND_MANTISSA          |   400 |\n    | QCBOR_DISABLE_PREFERRED_FLOAT           |   900 |\n    | QCBOR_DISABLE_FLOAT_HW_USE              |    50 |\n    | QCBOR_DISABLE_TAGS                      |   400 |\n    | QCBOR_DISABLE_NON_INTEGER_LABELS        |   140 |\n    | USEFULBUF_DISABLE_ALL_FLOAT             |   950 |\n\nQCBOR_DISABLE_ENCODE_USAGE_GUARDS affects encoding only.  It doesn't\ndisable any encoding features, just some error checking.  Disable it\nwhen you are confident that an encoding implementation is complete and\ncorrect.\n\nIndefinite lengths are a feature of CBOR that makes encoding simpler\nand the decoding more complex. They allow the encoder to not have to\nknow the length of a string, map or array when they start encoding\nit. Their main use is when encoding has to be done on a very\nconstrained device.  Conversely when decoding on a very constrained\ndevice, it is good to prohibit use of indefinite lengths so the\ndecoder can be smaller.\n\nThe QCBOR decode API processes both definite and indefinite lengths\nwith the same API, except to decode indefinite-length strings a\nstorage allocator must be configured.\n\nTo reduce the size of the decoder define\nQCBOR_DISABLE_INDEFINITE_LENGTH_STRINGS particularly if you are not\nconfiguring a storage allocator.\n\nFurther reduction can be by defining\nQCBOR_DISABLE_INDEFINITE_LENGTH_ARRAYS which will result in an error\nwhen an indefinite-length map or array arrives for decoding.\n\nQCBOR_DISABLE_UNCOMMON_TAGS disables the decoding of explicit tags for\nbase 64, regex, UUID and MIME data. This just disables the automatic\nrecognition of these from a major type 6 tag.\n\nQCBOR_DISABLE_EXP_AND_MANTISSA disables the decoding of decimal\nfractions and big floats.\n\nQCBOR_DISABLE_TAGS disables all decoding of CBOR tags. If the input has\na single tag, the error is unrecoverable so it is suitable only for protocols that\nhave no tags. \"Borrowed\" tag content formats (e.g. an epoch-based date\nwithout the tag number), can still be processed.\n\nQCBOR_DISABLE_NON_INTEGER_LABELS causes any label that doesn't\nfit in an int64_t to result in a QCBOR_ERR_MAP_LABEL_TYPE error.\nThis also disables QCBOR_DECODE_MODE_MAP_AS_ARRAY and \nQCBOR_DECODE_MODE_MAP_STRINGS_ONLY. It is fairly common for CBOR-based\nprotocols to use only small integers as labels.\n\nSee the discussion above on floating-point.\n\n ### Size of spiffy decode\n\n When creating a decode implementation, there is a choice of whether\n or not to use spiffy decode features or to just use\n QCBORDecode_GetNext().\n\n The implementation using spiffy decode will be simpler resulting in\n the calling code being smaller, but the amount of code brought in\n from the QCBOR library will be larger. Basic use of spiffy decode\n brings in about 2KB of object code.  If object code size is not a\n concern, then it is probably better to use spiffy decode because it\n is less work, there is less complexity and less testing to worry\n about.\n\n If code size is a concern, then use of QCBORDecode_GetNext() will\n probably result in smaller overall code size for simpler CBOR\n protocols. However, if the CBOR protocol is complex then use of\n spiffy decode may reduce overall code size.  An example of a complex\n protocol is one that involves decoding a lot of maps or maps that\n have many data items in them.  The overall code may be smaller\n because the general purpose spiffy decode map processor is the one\n used for all the maps.\n\n\n## Other Software Using QCBOR\n\n* [t_cose](https://github.com/laurencelundblade/t_cose) implements enough of\n[COSE, RFC 8152](https://tools.ietf.org/html/rfc8152) to support\n[CBOR Web Token (CWT)](https://tools.ietf.org/html/rfc8392) and\n[Entity Attestation Token (EAT)](https://tools.ietf.org/html/draft-ietf-rats-eat-06).\nSpecifically it supports signing and verification of the COSE_Sign1 message.\n\n* [ctoken](https://github.com/laurencelundblade/ctoken) is an implementation of\nEAT and CWT.\n\n## Credits\n* Ganesh Kanike for porting to QSEE\n* Mark Bapst for sponsorship and release as open source by Qualcomm\n* Sachin Sharma for release through CAF\n* Tamas Ban for porting to TF-M and 32-bit ARM\n* Michael Eckel for Makefile improvements\n* Jan Jongboom for indefinite length encoding\n* Peter Uiterwijk for error strings and other\n* Michael Richarson for CI set up and fixing some compiler warnings\n* Máté Tóth-Pál for float-point disabling and other\n* Dave Thaler for portability to Windows\n\n## Copyright and License\n\nQCBOR is available under what is essentially the 3-Clause BSD License.\n\nFiles created inside Qualcomm and open-sourced through CAF (The Code\nAurora Forum) have a slightly modified 3-Clause BSD License. The\nmodification additionally disclaims NON-INFRINGEMENT.\n\nFiles created after release to CAF use the standard 3-Clause BSD\nLicense with no modification. These files have the SPDX license\nidentifier, \"SPDX-License-Identifier: BSD-3-Clause\" in them.\n\n### BSD-3-Clause license\n\n* Redistributions of source code must retain the above copyright\nnotice, this list of conditions and the following disclaimer.\n\n* Redistributions in binary form must reproduce the above copyright\nnotice, this list of conditions and the following disclaimer in the\ndocumentation and/or other materials provided with the distribution.\n\n* Neither the name of the copyright holder nor the names of its\ncontributors may be used to endorse or promote products derived from\nthis software without specific prior written permission.\n\nTHIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS\n\"AS IS\" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT\nLIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR\nA PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT\nHOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,\nSPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT\nLIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,\nDATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY\nTHEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT\n(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE\nOF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.\n\n### Copyright for this README\n\nCopyright (c) 2018-2024, Laurence Lundblade. All rights reserved.\nCopyright (c) 2021-2023, Arm Limited. All rights reserved.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Flaurencelundblade%2FQCBOR","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Flaurencelundblade%2FQCBOR","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Flaurencelundblade%2FQCBOR/lists"}