Re: [Cbor] Using cddl-control to dissect byte strings

[Carsten Bormann <[e-mail]>]

On 2021-07-30, at 14:43, Christian Amsüss <[e-mail]> wrote:
> 
>> You mentioned the cddl tool generator — does the validator choke on this?
[…]
> 
>    CDDL validation failure

Yeah, I just looked at the code I wrote 2020-11-17.
The generator is fine, the validator focuses on the case where both lhs and rhs are single value (“extractable”) types; it probably should have a better message than “?” for when that is not the case.

>    [ full output at the end of the mail ]
> 
>> (I don’t want to think about .det here.)
> 
> For purposes of parser building (which is even stricter than validation,
> for validation probably doesn't need to find a *unique* assignment),
> there are reversible and irreversible controls; det is just
> irreversible, as is `bstr .cat bstr` without further constraints.

`bstr .cat bstr` is rather easy to match :-)

In this case, there simply is ambiguity where the bytes go (and the number of solutions is exactly the number of input bytes).
(It is not quite clear how to apply “preferred choice” here; greedy matching might be the equivalent.
Hope that uncertainty doesn’t stop us from going forward with .cat.)

Parsing (as opposed to matching) regexps have greedy and non-greedy occurrence indicators to disambiguate various use cases of this.
But the complexity of regexp code is exactly what I wouldn’t want in CDDL…

So I’d stick with the observation that you can write CDDL that tools will have trouble with.  I’d like to be able to cover at least

(bstr .size nn) .cat bstr
and
bstr .cat (bstr .size nn)

in a future version of the tool, but as soon as nn is a multi-value type (e.g., range), we’d need to invoke preferred choice again.

Grüße, Carsten