Closed maxd-nordic closed 1 year ago
Nevermind, this was with version 0.4.0. With 0.7.0, it doesn't pass validation:
Parsing files: from-device.cddl, /home/maxd/.local/lib/python3.8/site-packages/zcbor/cddl/prelude.cddl
Traceback (most recent call last):
File "/home/maxd/.local/bin/zcbor", line 8, in <module>
sys.exit(main())
File "/home/maxd/.local/lib/python3.8/site-packages/zcbor/zcbor.py", line 3168, in main
args.process(args)
File "/home/maxd/.local/lib/python3.8/site-packages/zcbor/zcbor.py", line 3025, in process_code
cddl_res[mode] = CodeGenerator.from_cddl(
File "/home/maxd/.local/lib/python3.8/site-packages/zcbor/zcbor.py", line 1730, in from_cddl
cddl_res = super(CodeGenerator, cddl_class).from_cddl(*args, **kwargs)
File "/home/maxd/.local/lib/python3.8/site-packages/zcbor/zcbor.py", line 283, in from_cddl
my_types[my_type].post_validate()
File "/home/maxd/.local/lib/python3.8/site-packages/zcbor/zcbor.py", line 917, in post_validate
raise TypeError(
TypeError: LIST[ message-type://OTHER'rsrp',
timestamp:UINT,
rsrp://OTHER'rsrp' => INT]
List member(s) cannot have key: [rsrp://OTHER'rsrp' => INT] pointing to []
Solution is to have different names.
Consider the following CDDL schema:
This is similar to RFC 8610 3.5.1, where keys are used for expressiveness, but ignored in the encoding.
The
zcbor
code generator gives me the following code:zcbor_uint32_put(state, (7)
is called twice, resulting in an incorrect encoding. This will generate [7, timestamp, 7, rsrp], but should do [7, timestamp, rsrp].