Skip to content

Conversation

@tahina-pro
Copy link
Member

#248 (comment) gives an example of CDDL specification that makes EverCDDL crash. This crash is due to the fact that the EverCDDL syntax parser tries to determine, at parsing time, whether an identifier will define a type or a group.

However, IETF RFC 8610 Appendix C says:

Note that whether the name
defined by a rule stands for a type or a group isn't always
determined by syntax alone: e.g., "a = b" can make "a" a type if "b"
is a type, or a group if "b" is a group. More subtly, in "a = (b)",
"a" may be used as a type if "b" is a type, or as a group both when
"b" is a group and when "b" is a type (a good convention to make the
latter case stand out to the human reader is to write "a = (b,)").
(Note that the same dual meaning of parentheses applies within an
expression but often can be resolved by the context of the
parenthesized expression. On the more general point, it may not be
clear immediately either whether "b" stands for a group or a type --
this semantic processing may need to span several levels of rule
definitions before a determination can be made.)

This means that determining whether a name will define a type or a group has to be done after the whole file has been parsed.

This PR fixes the EverCDDL syntax parser accordingly. First, we adapt the CDDL semantics to allow type names for GDef, i.e. at places where a group is expected but the user gives a type name instead. Then, we fix the CDDL syntax parser to not record the type-or-group kind of an identifier, but to return a name in all cases where the parser cannot determine whether it is parsing a type or a group expression. Then, the parser generates a program where definitions can be of the form a = b where a and b are names, without any knowledge of whether a and b should be types or groups. Then, a simple algorithm resolves type-or-group kinds after all definitions have been parsed.

This PR also introduces a loop detector, to reject a CDDL specification if it ends up producing a syntax parsing loop.

This is enough to have EverCDDL produce code for the large example at #248 (comment)

… the fact

from RFC 8610 Appendix C:

   Note that whether the name
   defined by a rule stands for a type or a group isn't always
   determined by syntax alone: e.g., "a = b" can make "a" a type if "b"
   is a type, or a group if "b" is a group.  More subtly, in "a = (b)",
   "a" may be used as a type if "b" is a type, or as a group both when
   "b" is a group and when "b" is a type (a good convention to make the
   latter case stand out to the human reader is to write "a = (b,)").
   (Note that the same dual meaning of parentheses applies within an
   expression but often can be resolved by the context of the
   parenthesized expression.  On the more general point, it may not be
   clear immediately either whether "b" stands for a group or a type --
   this semantic processing may need to span several levels of rule
   definitions before a determination can be made.)
necessary for array iterators with unit pair types
@tahina-pro tahina-pro merged commit b73b972 into project-everest:master Jan 27, 2026
17 checks passed
@tahina-pro tahina-pro deleted the _taramana_cddl_parser branch January 27, 2026 15:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant