Type with (size) constraint

[v0-e]

Consider the following definitions:

A ::= SEQUENCE SIZE(1..8) OF INTEGER
B ::= A (SIZE(2))

The compiler will abort in the assertion: asn1c: asn1fix_crange.c:1079: asn1constraint_compute_constraint_range: Assertion 'ct->el_count == 1' failed.

This is happens upon checking B's constraints where the fixer finds it has a SizeConstraint (derived from its parent) but more than one constraint element (A's SIZE constraint and B's constraint).

This issue happens whatever B's constraint is. In this example it is a SizeConstraint but it can be any other type, another example.

This easily fixable by adding parenthesis to A's SIZE. This effectively makes the parser interpret the constraint as a generalized Constraint, considered as a set of constraints by the compiler rather than just a SizeConstraint which considers only one constraint element.

If the parenthesis must be there or not is probably a question related with the interpretation of the ASN.1 standard. For example, should B's definition must be illegal because A's constraint is not inside parenthesis? OSS playground does not complain about that.

A possible solution is provided here. This fix is derived from an interpretation of X.680 (2021) section 49.5 provided note, where a SizeConstraint is just a subset of a generalized Constraint. This fix does have the side effect of the printed-after-parsing definition carrying now a parenthesis around the SIZE constraints, as it can be seen in the tests.

I am not sure if this is the best solution, given the change required in the tests. Possibly another solution maybe changing something in the fixer.

[mouse07410]

@velichkov, what is your opinion on this?

@v0-e would you consider submitting a PR?

[mouse07410]

@v0-e after some thinking I decided to adopt the approach that you pointed at. It's now in the vlm_master branch.

[mouse07410]

I guess we can close this issue now?

[v0-e]

Thank you. Yes, it can be closed.