Latest Threat Research:SANDWORM_MODE: Shai-Hulud-Style npm Worm Hijacks CI Workflows and Poisons AI Toolchains.Details →
Socket
Book a DemoInstallSign in
Socket
Book a DemoInstallSign in

zcbor

Package Overview
Dependencies
Maintainers
1
Versions
9
Alerts
File Explorer

Advanced tools

License
Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

zcbor - npm Package Compare versions

Comparing version
0.5.1
 to
0.6.0
+19
-3
include/zcbor_common.h

@@ -9,2 +9,3 @@ /*

#define ZCBOR_COMMON_H__
#include <stdint.h>

@@ -14,2 +15,5 @@ #include <stdbool.h>

#ifdef __cplusplus
extern "C" {
#endif

@@ -40,3 +44,3 @@ /** Convenience type that allows pointing to strings directly inside the payload

#ifdef ZCBOR_VERBOSE
#include <sys/printk.h>
#include <zephyr/sys/printk.h>
#define zcbor_trace() (printk("bytes left: %zu, byte: 0x%x, elem_count: 0x%" PRIxFAST32 ", err: %d, %s:%d\n",\

@@ -68,4 +72,12 @@ (size_t)state->payload_end - (size_t)state->payload, *state->payload, state->elem_count, \

} while(0)
#define zcbor_assert_state(expr, ...) \
do { \
if (!(expr)) { \
zcbor_print_assert(expr, __VA_ARGS__); \
ZCBOR_ERR(ZCBOR_ERR_ASSERTION); \
} \
} while(0)
#else
#define zcbor_assert(expr, ...)
#define zcbor_assert_state(expr, ...)
#endif

@@ -77,4 +89,4 @@

#ifndef ARRAY_SIZE
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
#ifndef ZCBOR_ARRAY_SIZE
#define ZCBOR_ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
#endif

@@ -394,2 +406,6 @@

#ifdef __cplusplus
}
#endif
#endif /* ZCBOR_COMMON_H__ */
+9
-0
include/zcbor_debug.h

@@ -9,2 +9,3 @@ /*

#define ZCBOR_DEBUG_H__
#include <stdint.h>

@@ -15,2 +16,6 @@ #include <stdbool.h>

#ifdef __cplusplus
extern "C" {
#endif
__attribute__((used))

@@ -62,2 +67,6 @@ static void zcbor_print_compare_lines(const uint8_t *str1, const uint8_t *str2, uint32_t size)

#ifdef __cplusplus
}
#endif
#endif /* ZCBOR_DEBUG_H__ */
+22
-7
include/zcbor_decode.h

@@ -9,2 +9,3 @@ /*

#define ZCBOR_DECODE_H__
#include <stdint.h>

@@ -15,2 +16,6 @@ #include <stdbool.h>

#ifdef __cplusplus
extern "C" {
#endif
/** The zcbor_decode library provides functions for decoding CBOR data elements.

@@ -58,6 +63,8 @@ *

/** Consume and expect a pint with a certain value, within a union.
/** Consume and expect a pint/nint with a certain value, within a union.
*
* Calls @ref zcbor_union_elem_code then @ref zcbor_uint32_expect.
* Calls @ref zcbor_union_elem_code then @ref zcbor_[u]int[32|64]_expect.
*/
bool zcbor_int32_expect_union(zcbor_state_t *state, int32_t result);
bool zcbor_int64_expect_union(zcbor_state_t *state, int64_t result);
bool zcbor_uint32_expect_union(zcbor_state_t *state, uint32_t result);

@@ -78,9 +85,13 @@ bool zcbor_uint64_expect_union(zcbor_state_t *state, uint64_t result);

*/
static inline bool zcbor_bstr_expect_ptr(zcbor_state_t *state, uint8_t *ptr, size_t len)
static inline bool zcbor_bstr_expect_ptr(zcbor_state_t *state, char const *ptr, size_t len)
{
return zcbor_bstr_expect(state, &(struct zcbor_string){.value = ptr, .len = len});
struct zcbor_string zs = { .value = (const uint8_t *)ptr, .len = len };
return zcbor_bstr_expect(state, &zs);
}
static inline bool zcbor_tstr_expect_ptr(zcbor_state_t *state, uint8_t *ptr, size_t len)
static inline bool zcbor_tstr_expect_ptr(zcbor_state_t *state, char const *ptr, size_t len)
{
return zcbor_tstr_expect(state, &(struct zcbor_string){.value = ptr, .len = len});
struct zcbor_string zs = { .value = (const uint8_t *)ptr, .len = len };
return zcbor_tstr_expect(state, &zs);
}

@@ -331,5 +342,9 @@

do { \
zcbor_new_decode_state(name, ARRAY_SIZE(name), payload, payload_size, elem_count); \
zcbor_new_decode_state(name, ZCBOR_ARRAY_SIZE(name), payload, payload_size, elem_count); \
} while(0)
#ifdef __cplusplus
}
#endif
#endif /* ZCBOR_DECODE_H__ */
+14
-5
include/zcbor_encode.h

@@ -9,2 +9,3 @@ /*

#define ZCBOR_ENCODE_H__
#include <stdint.h>

@@ -15,2 +16,6 @@ #include <stdbool.h>

#ifdef __cplusplus
extern "C" {
#endif
/** The zcbor_encode library provides functions for encoding CBOR data elements.

@@ -61,11 +66,11 @@ *

*/
static inline bool zcbor_bstr_encode_ptr(zcbor_state_t *state, const uint8_t *ptr, size_t len)
static inline bool zcbor_bstr_encode_ptr(zcbor_state_t *state, const char *ptr, size_t len)
{
const struct zcbor_string zs = { .value = ptr, .len = len };
const struct zcbor_string zs = { .value = (const uint8_t *)ptr, .len = len };
return zcbor_bstr_encode(state, &zs);
}
static inline bool zcbor_tstr_encode_ptr(zcbor_state_t *state, const uint8_t *ptr, size_t len)
static inline bool zcbor_tstr_encode_ptr(zcbor_state_t *state, const char *ptr, size_t len)
{
const struct zcbor_string zs = { .value = ptr, .len = len };
const struct zcbor_string zs = { .value = (const uint8_t *)ptr, .len = len };

@@ -278,5 +283,9 @@ return zcbor_tstr_encode(state, &zs);

do { \
zcbor_new_encode_state(name, ARRAY_SIZE(name), payload, payload_size, elem_count); \
zcbor_new_encode_state(name, ZCBOR_ARRAY_SIZE(name), payload, payload_size, elem_count); \
} while(0)
#ifdef __cplusplus
}
#endif
#endif /* ZCBOR_ENCODE_H__ */
+142
-96
PKG-INFO
Metadata-Version: 2.1
Name: zcbor
Version: 0.5.1
Version: 0.6.0
Summary: zcbor

@@ -22,3 +22,3 @@ Home-page: https://github.com/NordicSemiconductor/zcbor

The validation part of the script can also work with YAML and JSON data.
The validation/conversion part of the script works with YAML and JSON data, in addition to CBOR.
It can for example validate a YAML file against a schema and convert it into CBOR.

@@ -30,7 +30,23 @@

Features
========
Here are some possible ways zcbor can be used:
- Python script and module:
- Validate a YAML/JSON file and translate it into CBOR e.g. for transmission.
- Validate a YAML/JSON/CBOR file before processing it with some other tool
- Decode and validate incoming CBOR data into human-readable YAML/JSON.
- As part of a python script that processes YAML/JSON/CBOR files. zcbor is compatible with PyYAML and can additionally provide validation and/or easier inspection via named tuples.
- C code:
- Generate C code for validating and decoding or encoding CBOR, for use in optimized or constrained environments, such as microcontrollers.
- Provide a low-footprint CBOR decoding/encoding library similar to TinyCBOR/QCBOR/NanoCBOR.
CBOR decoding/encoding library
==============================
The CBOR library found at [headers](https://github.com/NordicSemiconductor/zcbor/tree/0.5.1/include) and [source](https://github.com/NordicSemiconductor/zcbor/tree/0.5.1/src) is used by the generated code, but can also be used directly.
If so, you must instantiate a `zcbor_state_t` object, which is most easily done using the `zcbor_new_*_state()` functions or the `ZCBOR_STATE_*()` macros.
The CBOR library found at [headers](https://github.com/NordicSemiconductor/zcbor/tree/0.6.0/include) and [source](https://github.com/NordicSemiconductor/zcbor/tree/0.6.0/src) is used by the generated code, but can also be used directly.
To use it, instantiate a `zcbor_state_t` object, which is most easily done using the `zcbor_new_*_state()` functions or the `ZCBOR_STATE_*()` macros.

@@ -84,27 +100,6 @@ The `elem_count` member refers to the number of encoded objects in the current list or map.

Schema-driven data manipulation and code generation
===================================================
By invoking `zcbor` (when installed via Pip or setup.py), or the Python script [zcbor.py](https://github.com/NordicSemiconductor/zcbor/blob/0.5.1/zcbor/zcbor.py) directly, you can generate C code that validates/encodes/decodes CBOR data conforming to a CDDL schema.
zcbor can also validate and convert CBOR data to and from JSON/YAML, either from the command line, or imported as a module.
Finally, the package contains a light-weight CBOR encoding/decoding library in C.
This library is used by the generated code, and can also be used directly in your own code.
Python script and module
========================
Features
========
Here are some possible ways zcbor can be used:
- Python scripting:
- Validate a YAML file and translate it into CBOR e.g. for transmission.
- Validate a YAML/JSON/CBOR file before processing it with some other tool
- Decode and validate incoming CBOR data into human-readable YAML/JSON.
- As part of a python script that processes YAML/JSON/CBOR files. zcbor is compatible with PyYAML and can additionally provide validation and/or easier inspection via named tuples.
- C code:
- Generate C code for validating and decoding or encoding CBOR, for use in optimized or constrained environments, such as microcontrollers.
- Provide a low-footprint CBOR decoding/encoding library similar to TinyCBOR/QCBOR/NanoCBOR.
Python scripting
================
Invoking zcbor.py from the command line

@@ -117,8 +112,9 @@ ---------------------------------------

The following is a generalized example for converting (and validating) data from the command line.
Following are some generalized examples for validating, and for converting (which also validates) data from the command line.
The script infers the data format from the file extension, but the format can also be specified explicitly.
See `zcbor convert --help` for more information.
See `zcbor validate --help` and `zcbor convert --help` for more information.
```sh
python3 <zcbor base>/zcbor/zcbor.py -c <CDDL description file> convert -t <which CDDL type to expect> -i <input data file> -o <output data file>
python3 <zcbor base>/zcbor/zcbor.py validate -c <CDDL description file> -t <which CDDL type to expect> -i <input data file>
python3 <zcbor base>/zcbor/zcbor.py convert -c <CDDL description file> -t <which CDDL type to expect> -i <input data file> -o <output data file>
```

@@ -129,3 +125,4 @@

```sh
zcbor -c <CDDL description file> convert -t <which CDDL type to expect> -i <input data file> -o <output data file>
zcbor validate -c <CDDL description file> -t <which CDDL type to expect> -i <input data file>
zcbor convert -c <CDDL description file> -t <which CDDL type to expect> -i <input data file> -o <output data file>
```

@@ -155,2 +152,3 @@

Code generation

@@ -170,3 +168,3 @@ ===============

There are tests for the code generation in [tests/](https://github.com/NordicSemiconductor/zcbor/tree/0.5.1/tests/).
There are tests for the code generation in [tests/](https://github.com/NordicSemiconductor/zcbor/tree/0.6.0/tests/).
The tests require [Zephyr](https://github.com/zephyrproject-rtos/zephyr) (if your shell is set up to build Zephyr samples, the tests should also build).

@@ -233,4 +231,5 @@

See [test3_simple](https://github.com/NordicSemiconductor/zcbor/tree/0.5.1/tests/decode/test3_simple/) for CDDL example code.
See [test3_simple](https://github.com/NordicSemiconductor/zcbor/tree/0.6.0/tests/decode/test3_simple/) for CDDL example code.
Introduction to CBOR

@@ -284,3 +283,3 @@ ====================

This example is is taken from [test3_simple](https://github.com/NordicSemiconductor/zcbor/tree/0.5.1/tests/decode/test3_simple/).
This example is is taken from [test3_simple](https://github.com/NordicSemiconductor/zcbor/tree/0.6.0/tests/decode/test3_simple/).

@@ -302,5 +301,5 @@ If your CDDL file contains the following code:

```sh
python3 <zcbor base>/zcbor/zcbor.py -c pet.cddl code -d -t Pet --oc pet_decode.c --oh pet_decode.h
python3 <zcbor base>/zcbor/zcbor.py code -c pet.cddl -d -t Pet --oc pet_decode.c --oh pet_decode.h
# or
zcbor -c pet.cddl code -d -t Pet --oc pet_decode.c --oh pet_decode.h
zcbor code -c pet.cddl -d -t Pet --oc pet_decode.c --oh pet_decode.h
```

@@ -376,5 +375,5 @@

```sh
python3 <zcbor base>/zcbor/zcbor.py -c pet.cddl convert -t Pet -i mypet.yaml -o mypet.cbor
python3 <zcbor base>/zcbor/zcbor.py convert -c pet.cddl -t Pet -i mypet.yaml -o mypet.cbor
# or
zcbor -c pet.cddl convert -t Pet -i mypet.yaml -o mypet.cbor
zcbor convert -c pet.cddl -t Pet -i mypet.yaml -o mypet.cbor
```

@@ -393,3 +392,3 @@

There are also test.sh scripts to quickly run all tests.
[`tests/test.sh`](https://github.com/NordicSemiconductor/zcbor/blob/0.5.1/tests/test.sh) runs all tests, including python tests in [`tests/scripts`](https://github.com/NordicSemiconductor/zcbor/tree/0.5.1/tests/scripts).
[`tests/test.sh`](https://github.com/NordicSemiconductor/zcbor/blob/0.6.0/tests/test.sh) runs all tests, including python tests in [`tests/scripts`](https://github.com/NordicSemiconductor/zcbor/tree/0.6.0/tests/scripts).

@@ -399,4 +398,5 @@ These tests are dependent upon the `pycodestyle` package from `pip`.

To set up the environment to run the ztest tests, follow [Zephyr's Getting Started Guide](https://docs.zephyrproject.org/latest/getting_started/index.html), or see the workflow in the [`.github`](https://github.com/NordicSemiconductor/zcbor/tree/0.5.1/.github) directory.
To set up the environment to run the ztest tests, follow [Zephyr's Getting Started Guide](https://docs.zephyrproject.org/latest/getting_started/index.html), or see the workflow in the [`.github`](https://github.com/NordicSemiconductor/zcbor/tree/0.6.0/.github) directory.
Command line documentation

@@ -411,37 +411,12 @@ ==========================

```
usage: zcbor [-h] [--version] -c CDDL [--default-max-qty DEFAULT_MAX_QTY]
[--no-prelude] [-v]
{code,convert} ...
usage: zcbor [-h] {code,validate,convert} ...
Parse a CDDL file and validate/convert between YAML, JSON, and CBOR. Can also
generate C code for validation/encoding/decoding of CBOR. Note that the other
top-level arguments (e.g. -c) must appear before {code/convert}. See zcbor
code/convert --help to see their respective specialized arguments.
generate C code for validation/encoding/decoding of CBOR.
positional arguments:
{code,convert}
{code,validate,convert}
options:
-h, --help show this help message and exit
--version show program's version number and exit
-c CDDL, --cddl CDDL Path to one or more input CDDL file(s). Passing
multiple files is equivalent to concatenating them.
--default-max-qty DEFAULT_MAX_QTY, --dq DEFAULT_MAX_QTY
Default maximum number of repetitions when no maximum
is specified. This is needed to construct complete C
types. This is relevant for the generated code. It is
not relevant for converting, except when handling data
that will be decoded by generated code. The default
value of this option is 3. Set it to a large number
when not relevant. When generating code, the
default_max_qty can usually be set to a text symbol,
to allow it to be configurable when building the code.
This is not always possible, as sometimes the value is
needed for internal computations. If so, the script
will raise an exception.
--no-prelude Exclude the standard CDDL prelude from the build. The
prelude can be viewed at zcbor/cddl/prelude.cddl in
the repo, or together with the script.
-v, --verbose Print more information while parsing CDDL and
generating code.

@@ -454,6 +429,7 @@ ```

```
usage: zcbor code [-h] [--output-c OUTPUT_C] [--output-h OUTPUT_H]
[--output-h-types OUTPUT_H_TYPES] [--copy-sources]
[--output-cmake OUTPUT_CMAKE] -t ENTRY_TYPES
[ENTRY_TYPES ...] [-d] [-e] [--time-header]
usage: zcbor code [-h] [--version] -c CDDL [--no-prelude] [-v]
[--default-max-qty DEFAULT_MAX_QTY] [--output-c OUTPUT_C]
[--output-h OUTPUT_H] [--output-h-types OUTPUT_H_TYPES]
[--copy-sources] [--output-cmake OUTPUT_CMAKE] -t
ENTRY_TYPES [ENTRY_TYPES ...] [-d] [-e] [--time-header]
[--git-sha-header] [-b {32,64}]

@@ -479,2 +455,19 @@ [--include-prefix INCLUDE_PREFIX] [-s]

-h, --help show this help message and exit
--version show program's version number and exit
-c CDDL, --cddl CDDL Path to one or more input CDDL file(s). Passing
multiple files is equivalent to concatenating them.
--no-prelude Exclude the standard CDDL prelude from the build. The
prelude can be viewed at zcbor/cddl/prelude.cddl in
the repo, or together with the script.
-v, --verbose Print more information while parsing CDDL and
generating code.
--default-max-qty DEFAULT_MAX_QTY, --dq DEFAULT_MAX_QTY
Default maximum number of repetitions when no maximum
is specified. This is needed to construct complete C
types. The default_max_qty can usually be set to a
text symbol if desired, to allow it to be configurable
when building the code. This is not always possible,
as sometimes the value is needed for internal
computations. If so, the script will raise an
exception.
--output-c OUTPUT_C, --oc OUTPUT_C

@@ -544,2 +537,42 @@ Path to output C file. If both --decode and --encode

zcbor validate --help
---------------------
```
usage: zcbor validate [-h] [--version] -c CDDL [--no-prelude] [-v]
[--default-max-qty DEFAULT_MAX_QTY] -i INPUT
[--input-as {yaml,json,cbor,cborhex}] -t ENTRY_TYPE
Read CBOR, YAML, or JSON data from file or stdin and validate it against a
CDDL schema file.
options:
-h, --help show this help message and exit
--version show program's version number and exit
-c CDDL, --cddl CDDL Path to one or more input CDDL file(s). Passing
multiple files is equivalent to concatenating them.
--no-prelude Exclude the standard CDDL prelude from the build. The
prelude can be viewed at zcbor/cddl/prelude.cddl in
the repo, or together with the script.
-v, --verbose Print more information while parsing CDDL and
generating code.
--default-max-qty DEFAULT_MAX_QTY, --dq DEFAULT_MAX_QTY
Default maximum number of repetitions when no maximum
is specified. It is only relevant when handling data
that will be decoded by generated code. If omitted, a
large number will be used.
-i INPUT, --input INPUT
Input data file. The option --input-as specifies how
to interpret the contents. Use "-" to indicate stdin.
--input-as {yaml,json,cbor,cborhex}
Which format to interpret the input file as. If
omitted, the format is inferred from the file name.
.yaml, .yml => YAML, .json => JSON, .cborhex => CBOR
as hex string, everything else => CBOR
-t ENTRY_TYPE, --entry-type ENTRY_TYPE
Name of the type (from the CDDL) to interpret the data
as.
```
zcbor convert --help

@@ -549,23 +582,25 @@ --------------------

```
usage: zcbor convert [-h] -i INPUT [--input-as {yaml,json,cbor,cborhex}]
[-o OUTPUT] [--output-as {yaml,json,cbor,cborhex,c_code}]
[--c-code-var-name C_CODE_VAR_NAME] -t ENTRY_TYPE
usage: zcbor convert [-h] [--version] -c CDDL [--no-prelude] [-v]
[--default-max-qty DEFAULT_MAX_QTY] -i INPUT
[--input-as {yaml,json,cbor,cborhex}] -t ENTRY_TYPE -o
OUTPUT [--output-as {yaml,json,cbor,cborhex,c_code}]
[--c-code-var-name C_CODE_VAR_NAME]
Parse a CDDL file and verify/convert between CBOR and YAML/JSON. The script
Parse a CDDL file and validate/convert between CBOR and YAML/JSON. The script
decodes the CBOR/YAML/JSON data from a file or stdin and verifies that it
conforms to the CDDL description. The script fails if the data does not
conform. The script can also be used to just verify. JSON and YAML do not
support all data types that CBOR/CDDL supports. bytestrings (BSTR), tags, and
maps with non-text keys need special handling: All strings in JSON/YAML are
text strings. If a BSTR is needed, use a dict with a single entry, with "bstr"
as the key, and the byte string (as a hex string) as the value, e.g. {"bstr":
"0123456789abcdef"}. The value can also be another type, e.g. which will be
interpreted as a BSTR with the given value as contents (in cddl: 'bstr .cbor
SomeType'). E.g. {"bstr": ["first element", 2, [3]]} Dicts in JSON/YAML only
support text strings for keys, so if a dict needs other types of keys,
encapsulate the key and value into a dict (n is an arbitrary integer): e.g.
{"name": "foo", "keyvaln": {"key": 123, "val": "bar"}} which will conform to
the CDDL {tstr => tstr, int => tstr}. Tags are specified by a dict with two
elements, e.g. {"tag": 1234, "value": ["tagged string within list"]}
'undefined' is specified as a list with a single text entry:
conform. 'zcbor validate' can be used if only validate is needed. JSON and
YAML do not support all data types that CBOR/CDDL supports. bytestrings
(BSTR), tags, and maps with non-text keys need special handling: All strings
in JSON/YAML are text strings. If a BSTR is needed, use a dict with a single
entry, with "bstr" as the key, and the byte string (as a hex string) as the
value, e.g. {"bstr": "0123456789abcdef"}. The value can also be another type,
e.g. which will be interpreted as a BSTR with the given value as contents (in
cddl: 'bstr .cbor SomeType'). E.g. {"bstr": ["first element", 2, [3]]} Dicts
in JSON/YAML only support text strings for keys, so if a dict needs other
types of keys, encapsulate the key and value into a dict (n is an arbitrary
integer): e.g. {"name": "foo", "keyvaln": {"key": 123, "val": "bar"}} which
will conform to the CDDL {tstr => tstr, int => tstr}. Tags are specified by a
dict with two elements, e.g. {"tag": 1234, "value": ["tagged string within
list"]} 'undefined' is specified as a list with a single text entry:
"zcbor_undefined".

@@ -575,2 +610,15 @@

-h, --help show this help message and exit
--version show program's version number and exit
-c CDDL, --cddl CDDL Path to one or more input CDDL file(s). Passing
multiple files is equivalent to concatenating them.
--no-prelude Exclude the standard CDDL prelude from the build. The
prelude can be viewed at zcbor/cddl/prelude.cddl in
the repo, or together with the script.
-v, --verbose Print more information while parsing CDDL and
generating code.
--default-max-qty DEFAULT_MAX_QTY, --dq DEFAULT_MAX_QTY
Default maximum number of repetitions when no maximum
is specified. It is only relevant when handling data
that will be decoded by generated code. If omitted, a
large number will be used.
-i INPUT, --input INPUT

@@ -584,7 +632,8 @@ Input data file. The option --input-as specifies how

as hex string, everything else => CBOR
-t ENTRY_TYPE, --entry-type ENTRY_TYPE
Name of the type (from the CDDL) to interpret the data
as.
-o OUTPUT, --output OUTPUT
Output data file. The option --output-as specifies how
to interpret the contents. If --output is omitted, no
conversion is done, only verification of the input.
Use "-" to indicate stdout.
to interpret the contents. Use "-" to indicate stdout.
--output-as {yaml,json,cbor,cborhex,c_code}

@@ -599,6 +648,3 @@ Which format to interpret the output file as. If

files.
-t ENTRY_TYPE, --entry-type ENTRY_TYPE
Name of the type (from the CDDL) to interpret the data
as.
```
+135
-89
README.md

@@ -7,3 +7,3 @@ zcbor

The validation part of the script can also work with YAML and JSON data.
The validation/conversion part of the script works with YAML and JSON data, in addition to CBOR.
It can for example validate a YAML file against a schema and convert it into CBOR.

@@ -15,2 +15,18 @@

Features
========
Here are some possible ways zcbor can be used:
- Python script and module:
- Validate a YAML/JSON file and translate it into CBOR e.g. for transmission.
- Validate a YAML/JSON/CBOR file before processing it with some other tool
- Decode and validate incoming CBOR data into human-readable YAML/JSON.
- As part of a python script that processes YAML/JSON/CBOR files. zcbor is compatible with PyYAML and can additionally provide validation and/or easier inspection via named tuples.
- C code:
- Generate C code for validating and decoding or encoding CBOR, for use in optimized or constrained environments, such as microcontrollers.
- Provide a low-footprint CBOR decoding/encoding library similar to TinyCBOR/QCBOR/NanoCBOR.
CBOR decoding/encoding library

@@ -20,3 +36,3 @@ ==============================

The CBOR library found at [headers](include) and [source](src) is used by the generated code, but can also be used directly.
If so, you must instantiate a `zcbor_state_t` object, which is most easily done using the `zcbor_new_*_state()` functions or the `ZCBOR_STATE_*()` macros.
To use it, instantiate a `zcbor_state_t` object, which is most easily done using the `zcbor_new_*_state()` functions or the `ZCBOR_STATE_*()` macros.

@@ -70,27 +86,6 @@ The `elem_count` member refers to the number of encoded objects in the current list or map.

Schema-driven data manipulation and code generation
===================================================
By invoking `zcbor` (when installed via Pip or setup.py), or the Python script [zcbor.py](zcbor/zcbor.py) directly, you can generate C code that validates/encodes/decodes CBOR data conforming to a CDDL schema.
zcbor can also validate and convert CBOR data to and from JSON/YAML, either from the command line, or imported as a module.
Finally, the package contains a light-weight CBOR encoding/decoding library in C.
This library is used by the generated code, and can also be used directly in your own code.
Python script and module
========================
Features
========
Here are some possible ways zcbor can be used:
- Python scripting:
- Validate a YAML file and translate it into CBOR e.g. for transmission.
- Validate a YAML/JSON/CBOR file before processing it with some other tool
- Decode and validate incoming CBOR data into human-readable YAML/JSON.
- As part of a python script that processes YAML/JSON/CBOR files. zcbor is compatible with PyYAML and can additionally provide validation and/or easier inspection via named tuples.
- C code:
- Generate C code for validating and decoding or encoding CBOR, for use in optimized or constrained environments, such as microcontrollers.
- Provide a low-footprint CBOR decoding/encoding library similar to TinyCBOR/QCBOR/NanoCBOR.
Python scripting
================
Invoking zcbor.py from the command line

@@ -103,8 +98,9 @@ ---------------------------------------

The following is a generalized example for converting (and validating) data from the command line.
Following are some generalized examples for validating, and for converting (which also validates) data from the command line.
The script infers the data format from the file extension, but the format can also be specified explicitly.
See `zcbor convert --help` for more information.
See `zcbor validate --help` and `zcbor convert --help` for more information.
```sh
python3 <zcbor base>/zcbor/zcbor.py -c <CDDL description file> convert -t <which CDDL type to expect> -i <input data file> -o <output data file>
python3 <zcbor base>/zcbor/zcbor.py validate -c <CDDL description file> -t <which CDDL type to expect> -i <input data file>
python3 <zcbor base>/zcbor/zcbor.py convert -c <CDDL description file> -t <which CDDL type to expect> -i <input data file> -o <output data file>
```

@@ -115,3 +111,4 @@

```sh
zcbor -c <CDDL description file> convert -t <which CDDL type to expect> -i <input data file> -o <output data file>
zcbor validate -c <CDDL description file> -t <which CDDL type to expect> -i <input data file>
zcbor convert -c <CDDL description file> -t <which CDDL type to expect> -i <input data file> -o <output data file>
```

@@ -141,2 +138,3 @@

Code generation

@@ -220,2 +218,3 @@ ===============

Introduction to CBOR

@@ -286,5 +285,5 @@ ====================

```sh
python3 <zcbor base>/zcbor/zcbor.py -c pet.cddl code -d -t Pet --oc pet_decode.c --oh pet_decode.h
python3 <zcbor base>/zcbor/zcbor.py code -c pet.cddl -d -t Pet --oc pet_decode.c --oh pet_decode.h
# or
zcbor -c pet.cddl code -d -t Pet --oc pet_decode.c --oh pet_decode.h
zcbor code -c pet.cddl -d -t Pet --oc pet_decode.c --oh pet_decode.h
```

@@ -360,5 +359,5 @@

```sh
python3 <zcbor base>/zcbor/zcbor.py -c pet.cddl convert -t Pet -i mypet.yaml -o mypet.cbor
python3 <zcbor base>/zcbor/zcbor.py convert -c pet.cddl -t Pet -i mypet.yaml -o mypet.cbor
# or
zcbor -c pet.cddl convert -t Pet -i mypet.yaml -o mypet.cbor
zcbor convert -c pet.cddl -t Pet -i mypet.yaml -o mypet.cbor
```

@@ -384,2 +383,3 @@

Command line documentation

@@ -394,37 +394,12 @@ ==========================

```
usage: zcbor [-h] [--version] -c CDDL [--default-max-qty DEFAULT_MAX_QTY]
[--no-prelude] [-v]
{code,convert} ...
usage: zcbor [-h] {code,validate,convert} ...
Parse a CDDL file and validate/convert between YAML, JSON, and CBOR. Can also
generate C code for validation/encoding/decoding of CBOR. Note that the other
top-level arguments (e.g. -c) must appear before {code/convert}. See zcbor
code/convert --help to see their respective specialized arguments.
generate C code for validation/encoding/decoding of CBOR.
positional arguments:
{code,convert}
{code,validate,convert}
options:
-h, --help show this help message and exit
--version show program's version number and exit
-c CDDL, --cddl CDDL Path to one or more input CDDL file(s). Passing
multiple files is equivalent to concatenating them.
--default-max-qty DEFAULT_MAX_QTY, --dq DEFAULT_MAX_QTY
Default maximum number of repetitions when no maximum
is specified. This is needed to construct complete C
types. This is relevant for the generated code. It is
not relevant for converting, except when handling data
that will be decoded by generated code. The default
value of this option is 3. Set it to a large number
when not relevant. When generating code, the
default_max_qty can usually be set to a text symbol,
to allow it to be configurable when building the code.
This is not always possible, as sometimes the value is
needed for internal computations. If so, the script
will raise an exception.
--no-prelude Exclude the standard CDDL prelude from the build. The
prelude can be viewed at zcbor/cddl/prelude.cddl in
the repo, or together with the script.
-v, --verbose Print more information while parsing CDDL and
generating code.

@@ -437,6 +412,7 @@ ```

```
usage: zcbor code [-h] [--output-c OUTPUT_C] [--output-h OUTPUT_H]
[--output-h-types OUTPUT_H_TYPES] [--copy-sources]
[--output-cmake OUTPUT_CMAKE] -t ENTRY_TYPES
[ENTRY_TYPES ...] [-d] [-e] [--time-header]
usage: zcbor code [-h] [--version] -c CDDL [--no-prelude] [-v]
[--default-max-qty DEFAULT_MAX_QTY] [--output-c OUTPUT_C]
[--output-h OUTPUT_H] [--output-h-types OUTPUT_H_TYPES]
[--copy-sources] [--output-cmake OUTPUT_CMAKE] -t
ENTRY_TYPES [ENTRY_TYPES ...] [-d] [-e] [--time-header]
[--git-sha-header] [-b {32,64}]

@@ -462,2 +438,19 @@ [--include-prefix INCLUDE_PREFIX] [-s]

-h, --help show this help message and exit
--version show program's version number and exit
-c CDDL, --cddl CDDL Path to one or more input CDDL file(s). Passing
multiple files is equivalent to concatenating them.
--no-prelude Exclude the standard CDDL prelude from the build. The
prelude can be viewed at zcbor/cddl/prelude.cddl in
the repo, or together with the script.
-v, --verbose Print more information while parsing CDDL and
generating code.
--default-max-qty DEFAULT_MAX_QTY, --dq DEFAULT_MAX_QTY
Default maximum number of repetitions when no maximum
is specified. This is needed to construct complete C
types. The default_max_qty can usually be set to a
text symbol if desired, to allow it to be configurable
when building the code. This is not always possible,
as sometimes the value is needed for internal
computations. If so, the script will raise an
exception.
--output-c OUTPUT_C, --oc OUTPUT_C

@@ -527,2 +520,42 @@ Path to output C file. If both --decode and --encode

zcbor validate --help
---------------------
```
usage: zcbor validate [-h] [--version] -c CDDL [--no-prelude] [-v]
[--default-max-qty DEFAULT_MAX_QTY] -i INPUT
[--input-as {yaml,json,cbor,cborhex}] -t ENTRY_TYPE
Read CBOR, YAML, or JSON data from file or stdin and validate it against a
CDDL schema file.
options:
-h, --help show this help message and exit
--version show program's version number and exit
-c CDDL, --cddl CDDL Path to one or more input CDDL file(s). Passing
multiple files is equivalent to concatenating them.
--no-prelude Exclude the standard CDDL prelude from the build. The
prelude can be viewed at zcbor/cddl/prelude.cddl in
the repo, or together with the script.
-v, --verbose Print more information while parsing CDDL and
generating code.
--default-max-qty DEFAULT_MAX_QTY, --dq DEFAULT_MAX_QTY
Default maximum number of repetitions when no maximum
is specified. It is only relevant when handling data
that will be decoded by generated code. If omitted, a
large number will be used.
-i INPUT, --input INPUT
Input data file. The option --input-as specifies how
to interpret the contents. Use "-" to indicate stdin.
--input-as {yaml,json,cbor,cborhex}
Which format to interpret the input file as. If
omitted, the format is inferred from the file name.
.yaml, .yml => YAML, .json => JSON, .cborhex => CBOR
as hex string, everything else => CBOR
-t ENTRY_TYPE, --entry-type ENTRY_TYPE
Name of the type (from the CDDL) to interpret the data
as.
```
zcbor convert --help

@@ -532,23 +565,25 @@ --------------------

```
usage: zcbor convert [-h] -i INPUT [--input-as {yaml,json,cbor,cborhex}]
[-o OUTPUT] [--output-as {yaml,json,cbor,cborhex,c_code}]
[--c-code-var-name C_CODE_VAR_NAME] -t ENTRY_TYPE
usage: zcbor convert [-h] [--version] -c CDDL [--no-prelude] [-v]
[--default-max-qty DEFAULT_MAX_QTY] -i INPUT
[--input-as {yaml,json,cbor,cborhex}] -t ENTRY_TYPE -o
OUTPUT [--output-as {yaml,json,cbor,cborhex,c_code}]
[--c-code-var-name C_CODE_VAR_NAME]
Parse a CDDL file and verify/convert between CBOR and YAML/JSON. The script
Parse a CDDL file and validate/convert between CBOR and YAML/JSON. The script
decodes the CBOR/YAML/JSON data from a file or stdin and verifies that it
conforms to the CDDL description. The script fails if the data does not
conform. The script can also be used to just verify. JSON and YAML do not
support all data types that CBOR/CDDL supports. bytestrings (BSTR), tags, and
maps with non-text keys need special handling: All strings in JSON/YAML are
text strings. If a BSTR is needed, use a dict with a single entry, with "bstr"
as the key, and the byte string (as a hex string) as the value, e.g. {"bstr":
"0123456789abcdef"}. The value can also be another type, e.g. which will be
interpreted as a BSTR with the given value as contents (in cddl: 'bstr .cbor
SomeType'). E.g. {"bstr": ["first element", 2, [3]]} Dicts in JSON/YAML only
support text strings for keys, so if a dict needs other types of keys,
encapsulate the key and value into a dict (n is an arbitrary integer): e.g.
{"name": "foo", "keyvaln": {"key": 123, "val": "bar"}} which will conform to
the CDDL {tstr => tstr, int => tstr}. Tags are specified by a dict with two
elements, e.g. {"tag": 1234, "value": ["tagged string within list"]}
'undefined' is specified as a list with a single text entry:
conform. 'zcbor validate' can be used if only validate is needed. JSON and
YAML do not support all data types that CBOR/CDDL supports. bytestrings
(BSTR), tags, and maps with non-text keys need special handling: All strings
in JSON/YAML are text strings. If a BSTR is needed, use a dict with a single
entry, with "bstr" as the key, and the byte string (as a hex string) as the
value, e.g. {"bstr": "0123456789abcdef"}. The value can also be another type,
e.g. which will be interpreted as a BSTR with the given value as contents (in
cddl: 'bstr .cbor SomeType'). E.g. {"bstr": ["first element", 2, [3]]} Dicts
in JSON/YAML only support text strings for keys, so if a dict needs other
types of keys, encapsulate the key and value into a dict (n is an arbitrary
integer): e.g. {"name": "foo", "keyvaln": {"key": 123, "val": "bar"}} which
will conform to the CDDL {tstr => tstr, int => tstr}. Tags are specified by a
dict with two elements, e.g. {"tag": 1234, "value": ["tagged string within
list"]} 'undefined' is specified as a list with a single text entry:
"zcbor_undefined".

@@ -558,2 +593,15 @@

-h, --help show this help message and exit
--version show program's version number and exit
-c CDDL, --cddl CDDL Path to one or more input CDDL file(s). Passing
multiple files is equivalent to concatenating them.
--no-prelude Exclude the standard CDDL prelude from the build. The
prelude can be viewed at zcbor/cddl/prelude.cddl in
the repo, or together with the script.
-v, --verbose Print more information while parsing CDDL and
generating code.
--default-max-qty DEFAULT_MAX_QTY, --dq DEFAULT_MAX_QTY
Default maximum number of repetitions when no maximum
is specified. It is only relevant when handling data
that will be decoded by generated code. If omitted, a
large number will be used.
-i INPUT, --input INPUT

@@ -567,7 +615,8 @@ Input data file. The option --input-as specifies how

as hex string, everything else => CBOR
-t ENTRY_TYPE, --entry-type ENTRY_TYPE
Name of the type (from the CDDL) to interpret the data
as.
-o OUTPUT, --output OUTPUT
Output data file. The option --output-as specifies how
to interpret the contents. If --output is omitted, no
conversion is done, only verification of the input.
Use "-" to indicate stdout.
to interpret the contents. Use "-" to indicate stdout.
--output-as {yaml,json,cbor,cborhex,c_code}

@@ -582,6 +631,3 @@ Which format to interpret the output file as. If

files.
-t ENTRY_TYPE, --entry-type ENTRY_TYPE
Name of the type (from the CDDL) to interpret the data
as.
```
+31
-9
src/zcbor_decode.c

@@ -31,3 +31,3 @@ /*

/** Extract the major type, i.e. the first 3 bits of the header byte. */
#define MAJOR_TYPE(header_byte) (((header_byte) >> 5) & 0x7)
#define MAJOR_TYPE(header_byte) ((zcbor_major_type_t)(((header_byte) >> 5) & 0x7))

@@ -116,4 +116,4 @@ /** Extract the additional info, i.e. the last 5 bits of the header byte. */

zcbor_trace();
zcbor_assert(result_len != 0, "0-length result not supported.\r\n");
zcbor_assert(result != NULL, NULL);
zcbor_assert_state(result_len != 0, "0-length result not supported.\r\n");
zcbor_assert_state(result != NULL, NULL);

@@ -163,3 +163,3 @@ INITIAL_CHECKS();

INITIAL_CHECKS();
uint8_t major_type = MAJOR_TYPE(*state->payload);
zcbor_major_type_t major_type = MAJOR_TYPE(*state->payload);
uint8_t *result_uint8 = (uint8_t *)result_int;

@@ -221,5 +221,25 @@ int8_t *result_int8 = (int8_t *)result_int;

bool zcbor_int32_expect_union(zcbor_state_t *state, int32_t result)
{
if (!zcbor_union_elem_code(state)) {
ZCBOR_FAIL();
}
return zcbor_int32_expect(state, result);
}
bool zcbor_int64_expect_union(zcbor_state_t *state, int64_t result)
{
if (!zcbor_union_elem_code(state)) {
ZCBOR_FAIL();
}
return zcbor_int64_expect(state, result);
}
bool zcbor_uint32_expect_union(zcbor_state_t *state, uint32_t result)
{
zcbor_union_elem_code(state);
if (!zcbor_union_elem_code(state)) {
ZCBOR_FAIL();
}
return zcbor_uint32_expect(state, result);

@@ -231,3 +251,5 @@ }

{
zcbor_union_elem_code(state);
if (!zcbor_union_elem_code(state)) {
ZCBOR_FAIL();
}
return zcbor_uint64_expect(state, result);

@@ -773,7 +795,7 @@ }

{
zcbor_assert(result == NULL,
zcbor_assert_state(result == NULL,
"'any' type cannot be returned, only skipped.\r\n");
INITIAL_CHECKS();
uint8_t major_type = MAJOR_TYPE(*state->payload);
zcbor_major_type_t major_type = MAJOR_TYPE(*state->payload);
uint8_t additional = ADDITIONAL(*state->payload);

@@ -920,3 +942,3 @@ uint_fast32_t value;

zcbor_assert(retval, "zcbor_multi_decode should not fail with these parameters.\r\n");
zcbor_assert_state(retval, "zcbor_multi_decode should not fail with these parameters.\r\n");

@@ -923,0 +945,0 @@ *present = num_decode;

+3
-3
src/zcbor_encode.c

@@ -46,3 +46,3 @@ /*

zcbor_assert(additional < 32, NULL);
zcbor_assert_state(additional < 32, NULL);

@@ -115,3 +115,3 @@ *(state->payload_mut++) = (uint8_t)((major_type << 5) | (additional & 0x1F));

#ifdef CONFIG_BIG_ENDIAN
return &((uint8_t *)input)[max_result_len - result_len];
return &((uint8_t *)input)[max_result_len - (result_len ? result_len : 1)];
#else

@@ -137,3 +137,3 @@ return input;

{
zcbor_assert(max_result_len != 0, "0-length result not supported.\r\n");
zcbor_assert_state(max_result_len != 0, "0-length result not supported.\r\n");

@@ -140,0 +140,0 @@ uint_fast32_t result_len = get_result_len(input, max_result_len);

+142
-96
zcbor.egg-info/PKG-INFO
Metadata-Version: 2.1
Name: zcbor
Version: 0.5.1
Version: 0.6.0
Summary: zcbor

@@ -22,3 +22,3 @@ Home-page: https://github.com/NordicSemiconductor/zcbor

The validation part of the script can also work with YAML and JSON data.
The validation/conversion part of the script works with YAML and JSON data, in addition to CBOR.
It can for example validate a YAML file against a schema and convert it into CBOR.

@@ -30,7 +30,23 @@

Features
========
Here are some possible ways zcbor can be used:
- Python script and module:
- Validate a YAML/JSON file and translate it into CBOR e.g. for transmission.
- Validate a YAML/JSON/CBOR file before processing it with some other tool
- Decode and validate incoming CBOR data into human-readable YAML/JSON.
- As part of a python script that processes YAML/JSON/CBOR files. zcbor is compatible with PyYAML and can additionally provide validation and/or easier inspection via named tuples.
- C code:
- Generate C code for validating and decoding or encoding CBOR, for use in optimized or constrained environments, such as microcontrollers.
- Provide a low-footprint CBOR decoding/encoding library similar to TinyCBOR/QCBOR/NanoCBOR.
CBOR decoding/encoding library
==============================
The CBOR library found at [headers](https://github.com/NordicSemiconductor/zcbor/tree/0.5.1/include) and [source](https://github.com/NordicSemiconductor/zcbor/tree/0.5.1/src) is used by the generated code, but can also be used directly.
If so, you must instantiate a `zcbor_state_t` object, which is most easily done using the `zcbor_new_*_state()` functions or the `ZCBOR_STATE_*()` macros.
The CBOR library found at [headers](https://github.com/NordicSemiconductor/zcbor/tree/0.6.0/include) and [source](https://github.com/NordicSemiconductor/zcbor/tree/0.6.0/src) is used by the generated code, but can also be used directly.
To use it, instantiate a `zcbor_state_t` object, which is most easily done using the `zcbor_new_*_state()` functions or the `ZCBOR_STATE_*()` macros.

@@ -84,27 +100,6 @@ The `elem_count` member refers to the number of encoded objects in the current list or map.

Schema-driven data manipulation and code generation
===================================================
By invoking `zcbor` (when installed via Pip or setup.py), or the Python script [zcbor.py](https://github.com/NordicSemiconductor/zcbor/blob/0.5.1/zcbor/zcbor.py) directly, you can generate C code that validates/encodes/decodes CBOR data conforming to a CDDL schema.
zcbor can also validate and convert CBOR data to and from JSON/YAML, either from the command line, or imported as a module.
Finally, the package contains a light-weight CBOR encoding/decoding library in C.
This library is used by the generated code, and can also be used directly in your own code.
Python script and module
========================
Features
========
Here are some possible ways zcbor can be used:
- Python scripting:
- Validate a YAML file and translate it into CBOR e.g. for transmission.
- Validate a YAML/JSON/CBOR file before processing it with some other tool
- Decode and validate incoming CBOR data into human-readable YAML/JSON.
- As part of a python script that processes YAML/JSON/CBOR files. zcbor is compatible with PyYAML and can additionally provide validation and/or easier inspection via named tuples.
- C code:
- Generate C code for validating and decoding or encoding CBOR, for use in optimized or constrained environments, such as microcontrollers.
- Provide a low-footprint CBOR decoding/encoding library similar to TinyCBOR/QCBOR/NanoCBOR.
Python scripting
================
Invoking zcbor.py from the command line

@@ -117,8 +112,9 @@ ---------------------------------------

The following is a generalized example for converting (and validating) data from the command line.
Following are some generalized examples for validating, and for converting (which also validates) data from the command line.
The script infers the data format from the file extension, but the format can also be specified explicitly.
See `zcbor convert --help` for more information.
See `zcbor validate --help` and `zcbor convert --help` for more information.
```sh
python3 <zcbor base>/zcbor/zcbor.py -c <CDDL description file> convert -t <which CDDL type to expect> -i <input data file> -o <output data file>
python3 <zcbor base>/zcbor/zcbor.py validate -c <CDDL description file> -t <which CDDL type to expect> -i <input data file>
python3 <zcbor base>/zcbor/zcbor.py convert -c <CDDL description file> -t <which CDDL type to expect> -i <input data file> -o <output data file>
```

@@ -129,3 +125,4 @@

```sh
zcbor -c <CDDL description file> convert -t <which CDDL type to expect> -i <input data file> -o <output data file>
zcbor validate -c <CDDL description file> -t <which CDDL type to expect> -i <input data file>
zcbor convert -c <CDDL description file> -t <which CDDL type to expect> -i <input data file> -o <output data file>
```

@@ -155,2 +152,3 @@

Code generation

@@ -170,3 +168,3 @@ ===============

There are tests for the code generation in [tests/](https://github.com/NordicSemiconductor/zcbor/tree/0.5.1/tests/).
There are tests for the code generation in [tests/](https://github.com/NordicSemiconductor/zcbor/tree/0.6.0/tests/).
The tests require [Zephyr](https://github.com/zephyrproject-rtos/zephyr) (if your shell is set up to build Zephyr samples, the tests should also build).

@@ -233,4 +231,5 @@

See [test3_simple](https://github.com/NordicSemiconductor/zcbor/tree/0.5.1/tests/decode/test3_simple/) for CDDL example code.
See [test3_simple](https://github.com/NordicSemiconductor/zcbor/tree/0.6.0/tests/decode/test3_simple/) for CDDL example code.
Introduction to CBOR

@@ -284,3 +283,3 @@ ====================

This example is is taken from [test3_simple](https://github.com/NordicSemiconductor/zcbor/tree/0.5.1/tests/decode/test3_simple/).
This example is is taken from [test3_simple](https://github.com/NordicSemiconductor/zcbor/tree/0.6.0/tests/decode/test3_simple/).

@@ -302,5 +301,5 @@ If your CDDL file contains the following code:

```sh
python3 <zcbor base>/zcbor/zcbor.py -c pet.cddl code -d -t Pet --oc pet_decode.c --oh pet_decode.h
python3 <zcbor base>/zcbor/zcbor.py code -c pet.cddl -d -t Pet --oc pet_decode.c --oh pet_decode.h
# or
zcbor -c pet.cddl code -d -t Pet --oc pet_decode.c --oh pet_decode.h
zcbor code -c pet.cddl -d -t Pet --oc pet_decode.c --oh pet_decode.h
```

@@ -376,5 +375,5 @@

```sh
python3 <zcbor base>/zcbor/zcbor.py -c pet.cddl convert -t Pet -i mypet.yaml -o mypet.cbor
python3 <zcbor base>/zcbor/zcbor.py convert -c pet.cddl -t Pet -i mypet.yaml -o mypet.cbor
# or
zcbor -c pet.cddl convert -t Pet -i mypet.yaml -o mypet.cbor
zcbor convert -c pet.cddl -t Pet -i mypet.yaml -o mypet.cbor
```

@@ -393,3 +392,3 @@

There are also test.sh scripts to quickly run all tests.
[`tests/test.sh`](https://github.com/NordicSemiconductor/zcbor/blob/0.5.1/tests/test.sh) runs all tests, including python tests in [`tests/scripts`](https://github.com/NordicSemiconductor/zcbor/tree/0.5.1/tests/scripts).
[`tests/test.sh`](https://github.com/NordicSemiconductor/zcbor/blob/0.6.0/tests/test.sh) runs all tests, including python tests in [`tests/scripts`](https://github.com/NordicSemiconductor/zcbor/tree/0.6.0/tests/scripts).

@@ -399,4 +398,5 @@ These tests are dependent upon the `pycodestyle` package from `pip`.

To set up the environment to run the ztest tests, follow [Zephyr's Getting Started Guide](https://docs.zephyrproject.org/latest/getting_started/index.html), or see the workflow in the [`.github`](https://github.com/NordicSemiconductor/zcbor/tree/0.5.1/.github) directory.
To set up the environment to run the ztest tests, follow [Zephyr's Getting Started Guide](https://docs.zephyrproject.org/latest/getting_started/index.html), or see the workflow in the [`.github`](https://github.com/NordicSemiconductor/zcbor/tree/0.6.0/.github) directory.
Command line documentation

@@ -411,37 +411,12 @@ ==========================

```
usage: zcbor [-h] [--version] -c CDDL [--default-max-qty DEFAULT_MAX_QTY]
[--no-prelude] [-v]
{code,convert} ...
usage: zcbor [-h] {code,validate,convert} ...
Parse a CDDL file and validate/convert between YAML, JSON, and CBOR. Can also
generate C code for validation/encoding/decoding of CBOR. Note that the other
top-level arguments (e.g. -c) must appear before {code/convert}. See zcbor
code/convert --help to see their respective specialized arguments.
generate C code for validation/encoding/decoding of CBOR.
positional arguments:
{code,convert}
{code,validate,convert}
options:
-h, --help show this help message and exit
--version show program's version number and exit
-c CDDL, --cddl CDDL Path to one or more input CDDL file(s). Passing
multiple files is equivalent to concatenating them.
--default-max-qty DEFAULT_MAX_QTY, --dq DEFAULT_MAX_QTY
Default maximum number of repetitions when no maximum
is specified. This is needed to construct complete C
types. This is relevant for the generated code. It is
not relevant for converting, except when handling data
that will be decoded by generated code. The default
value of this option is 3. Set it to a large number
when not relevant. When generating code, the
default_max_qty can usually be set to a text symbol,
to allow it to be configurable when building the code.
This is not always possible, as sometimes the value is
needed for internal computations. If so, the script
will raise an exception.
--no-prelude Exclude the standard CDDL prelude from the build. The
prelude can be viewed at zcbor/cddl/prelude.cddl in
the repo, or together with the script.
-v, --verbose Print more information while parsing CDDL and
generating code.

@@ -454,6 +429,7 @@ ```

```
usage: zcbor code [-h] [--output-c OUTPUT_C] [--output-h OUTPUT_H]
[--output-h-types OUTPUT_H_TYPES] [--copy-sources]
[--output-cmake OUTPUT_CMAKE] -t ENTRY_TYPES
[ENTRY_TYPES ...] [-d] [-e] [--time-header]
usage: zcbor code [-h] [--version] -c CDDL [--no-prelude] [-v]
[--default-max-qty DEFAULT_MAX_QTY] [--output-c OUTPUT_C]
[--output-h OUTPUT_H] [--output-h-types OUTPUT_H_TYPES]
[--copy-sources] [--output-cmake OUTPUT_CMAKE] -t
ENTRY_TYPES [ENTRY_TYPES ...] [-d] [-e] [--time-header]
[--git-sha-header] [-b {32,64}]

@@ -479,2 +455,19 @@ [--include-prefix INCLUDE_PREFIX] [-s]

-h, --help show this help message and exit
--version show program's version number and exit
-c CDDL, --cddl CDDL Path to one or more input CDDL file(s). Passing
multiple files is equivalent to concatenating them.
--no-prelude Exclude the standard CDDL prelude from the build. The
prelude can be viewed at zcbor/cddl/prelude.cddl in
the repo, or together with the script.
-v, --verbose Print more information while parsing CDDL and
generating code.
--default-max-qty DEFAULT_MAX_QTY, --dq DEFAULT_MAX_QTY
Default maximum number of repetitions when no maximum
is specified. This is needed to construct complete C
types. The default_max_qty can usually be set to a
text symbol if desired, to allow it to be configurable
when building the code. This is not always possible,
as sometimes the value is needed for internal
computations. If so, the script will raise an
exception.
--output-c OUTPUT_C, --oc OUTPUT_C

@@ -544,2 +537,42 @@ Path to output C file. If both --decode and --encode

zcbor validate --help
---------------------
```
usage: zcbor validate [-h] [--version] -c CDDL [--no-prelude] [-v]
[--default-max-qty DEFAULT_MAX_QTY] -i INPUT
[--input-as {yaml,json,cbor,cborhex}] -t ENTRY_TYPE
Read CBOR, YAML, or JSON data from file or stdin and validate it against a
CDDL schema file.
options:
-h, --help show this help message and exit
--version show program's version number and exit
-c CDDL, --cddl CDDL Path to one or more input CDDL file(s). Passing
multiple files is equivalent to concatenating them.
--no-prelude Exclude the standard CDDL prelude from the build. The
prelude can be viewed at zcbor/cddl/prelude.cddl in
the repo, or together with the script.
-v, --verbose Print more information while parsing CDDL and
generating code.
--default-max-qty DEFAULT_MAX_QTY, --dq DEFAULT_MAX_QTY
Default maximum number of repetitions when no maximum
is specified. It is only relevant when handling data
that will be decoded by generated code. If omitted, a
large number will be used.
-i INPUT, --input INPUT
Input data file. The option --input-as specifies how
to interpret the contents. Use "-" to indicate stdin.
--input-as {yaml,json,cbor,cborhex}
Which format to interpret the input file as. If
omitted, the format is inferred from the file name.
.yaml, .yml => YAML, .json => JSON, .cborhex => CBOR
as hex string, everything else => CBOR
-t ENTRY_TYPE, --entry-type ENTRY_TYPE
Name of the type (from the CDDL) to interpret the data
as.
```
zcbor convert --help

@@ -549,23 +582,25 @@ --------------------

```
usage: zcbor convert [-h] -i INPUT [--input-as {yaml,json,cbor,cborhex}]
[-o OUTPUT] [--output-as {yaml,json,cbor,cborhex,c_code}]
[--c-code-var-name C_CODE_VAR_NAME] -t ENTRY_TYPE
usage: zcbor convert [-h] [--version] -c CDDL [--no-prelude] [-v]
[--default-max-qty DEFAULT_MAX_QTY] -i INPUT
[--input-as {yaml,json,cbor,cborhex}] -t ENTRY_TYPE -o
OUTPUT [--output-as {yaml,json,cbor,cborhex,c_code}]
[--c-code-var-name C_CODE_VAR_NAME]
Parse a CDDL file and verify/convert between CBOR and YAML/JSON. The script
Parse a CDDL file and validate/convert between CBOR and YAML/JSON. The script
decodes the CBOR/YAML/JSON data from a file or stdin and verifies that it
conforms to the CDDL description. The script fails if the data does not
conform. The script can also be used to just verify. JSON and YAML do not
support all data types that CBOR/CDDL supports. bytestrings (BSTR), tags, and
maps with non-text keys need special handling: All strings in JSON/YAML are
text strings. If a BSTR is needed, use a dict with a single entry, with "bstr"
as the key, and the byte string (as a hex string) as the value, e.g. {"bstr":
"0123456789abcdef"}. The value can also be another type, e.g. which will be
interpreted as a BSTR with the given value as contents (in cddl: 'bstr .cbor
SomeType'). E.g. {"bstr": ["first element", 2, [3]]} Dicts in JSON/YAML only
support text strings for keys, so if a dict needs other types of keys,
encapsulate the key and value into a dict (n is an arbitrary integer): e.g.
{"name": "foo", "keyvaln": {"key": 123, "val": "bar"}} which will conform to
the CDDL {tstr => tstr, int => tstr}. Tags are specified by a dict with two
elements, e.g. {"tag": 1234, "value": ["tagged string within list"]}
'undefined' is specified as a list with a single text entry:
conform. 'zcbor validate' can be used if only validate is needed. JSON and
YAML do not support all data types that CBOR/CDDL supports. bytestrings
(BSTR), tags, and maps with non-text keys need special handling: All strings
in JSON/YAML are text strings. If a BSTR is needed, use a dict with a single
entry, with "bstr" as the key, and the byte string (as a hex string) as the
value, e.g. {"bstr": "0123456789abcdef"}. The value can also be another type,
e.g. which will be interpreted as a BSTR with the given value as contents (in
cddl: 'bstr .cbor SomeType'). E.g. {"bstr": ["first element", 2, [3]]} Dicts
in JSON/YAML only support text strings for keys, so if a dict needs other
types of keys, encapsulate the key and value into a dict (n is an arbitrary
integer): e.g. {"name": "foo", "keyvaln": {"key": 123, "val": "bar"}} which
will conform to the CDDL {tstr => tstr, int => tstr}. Tags are specified by a
dict with two elements, e.g. {"tag": 1234, "value": ["tagged string within
list"]} 'undefined' is specified as a list with a single text entry:
"zcbor_undefined".

@@ -575,2 +610,15 @@

-h, --help show this help message and exit
--version show program's version number and exit
-c CDDL, --cddl CDDL Path to one or more input CDDL file(s). Passing
multiple files is equivalent to concatenating them.
--no-prelude Exclude the standard CDDL prelude from the build. The
prelude can be viewed at zcbor/cddl/prelude.cddl in
the repo, or together with the script.
-v, --verbose Print more information while parsing CDDL and
generating code.
--default-max-qty DEFAULT_MAX_QTY, --dq DEFAULT_MAX_QTY
Default maximum number of repetitions when no maximum
is specified. It is only relevant when handling data
that will be decoded by generated code. If omitted, a
large number will be used.
-i INPUT, --input INPUT

@@ -584,7 +632,8 @@ Input data file. The option --input-as specifies how

as hex string, everything else => CBOR
-t ENTRY_TYPE, --entry-type ENTRY_TYPE
Name of the type (from the CDDL) to interpret the data
as.
-o OUTPUT, --output OUTPUT
Output data file. The option --output-as specifies how
to interpret the contents. If --output is omitted, no
conversion is done, only verification of the input.
Use "-" to indicate stdout.
to interpret the contents. Use "-" to indicate stdout.
--output-as {yaml,json,cbor,cborhex,c_code}

@@ -599,6 +648,3 @@ Which format to interpret the output file as. If

files.
-t ENTRY_TYPE, --entry-type ENTRY_TYPE
Name of the type (from the CDDL) to interpret the data
as.
```
+1
-1
zcbor/VERSION

@@ -1,1 +0,1 @@

0.5.1
0.6.0
zcbor/zcbor.py

Sorry, the diff of this file is too big to display