Closed v0-e closed 8 months ago
@velichkov, what is your opinion on this?
@v0-e would you consider submitting a PR?
@v0-e after some thinking I decided to adopt the approach that you pointed at. It's now in the vlm_master
branch.
I guess we can close this issue now?
Thank you. Yes, it can be closed.
Consider the following definitions:
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 aSizeConstraint
(derived from its parent) but more than one constraint element (A
'sSIZE
constraint andB
's constraint).This issue happens whatever
B
's constraint is. In this example it is aSizeConstraint
but it can be any other type, another example.This easily fixable by adding parenthesis to
A
'sSIZE
. This effectively makes the parser interpret the constraint as a generalizedConstraint
, considered as a set of constraints by the compiler rather than just aSizeConstraint
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 becauseA
'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 generalizedConstraint
. This fix does have the side effect of the printed-after-parsing definition carrying now a parenthesis around theSIZE
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.