ASN.1 decode failure in case of extendable size constraint

[palyamate]

I used this simplified ASN.1 file:

FOO

DEFINITIONS AUTOMATIC TAGS ::=

BEGIN

Foo ::= SEQUENCE {
    bars           SEQUENCE (SIZE (1..4), ...) OF Bar,
    ...
}

Bar ::= SEQUENCE {
    baz   INTEGER(1..4, ...)
}

END

I used several tools e.g. this for compiling and using this scheme. I encoded this:

{
    "bars": [
        {
            "baz": 3
        }
    ]
}

I used the UPER encoding and got the result in hex: 04 When I compiled with _pycrateasn1compile.py and used the generated class to decode the result bytes and got this: {'bars': [{'baz': 2}]} I investigated the encoding/decoding and found that the generated code has this line: _Foo_bars._const_sz = ASN1Set(rv=[], rr=[ASN1RangeInt(lb=1, ub=4)], ev=None, er=[]) The ev is None but I think it should be [], if I understand it right. I changed it to [], and the decoding got correct, so I got the same JSON as with the other tools. Then, I changed a line in the ASN.1 file: bars SEQUENCE (SIZE (1..4, ...)) OF Bar, And the generated ASN.1 file now has this line: _Foo_bars._const_sz = ASN1Set(rv=[], rr=[ASN1RangeInt(lb=1, ub=4)], ev=[], er=[]) So the ev is an empty list and the decoding is still correct. I think the problem is that these 2 lines should result the same generated code, as with the other tools. bars SEQUENCE (SIZE (1..4, ...)) OF Bar, bars SEQUENCE (SIZE (1..4), ...) OF Bar,

[p1-bmu]

Thanks for your feedback on this. My understanding of ITU-T X.680 (I just re-checked it) is that only the first kind of notation is valid for an extensible SIZE constraint: bars SEQUENCE (SIZE (1..4, ...)) OF Bar. In the 2nd notation bars SEQUENCE (SIZE (1..4), ...) OF Bar, the extension would apply to any kind of constraint on the parent type, and not specifically to the values of the SIZE constraint (even if it does not always makes sense...).

Do you have any reference into the ASN.1 specification which indicates that this 2nd notation would be valid for the SIZE constraint ?

[palyamate]

I couldn't really find anything in the X.680 which would clarify that for me. But maybe the X.680 is not enough on its own for this kind of problem because PER-visibility can overwrite it in some cases. In X.691 at B.3, the examples has some similar constraints, but it's combination of alphabet and size constraint, so not exactly the same. I just want to show off that what you writed is correct, I think, but in the PER encoding, maybe it's not. And maybe the examples can clarify it for you. And here are a curiosity, a similar conversation that I found (but again, unfortunately I couldn't find the evidence on the standard and it's really old): https://www.mail-archive.com/asn1@oss.com/msg01317.html

[p1-bmu]

OK, from the discussion on the archive, it seems this constraint extension notation should impact the SIZE one (as all others), and thus impact the PER encoding. I'll check how to support it.

[p1-bmu]

I just pushed some fixes and enhancement to the asn1 compiler part. One of it enables to process the notation you need for your module. Have a look to it, and please indicate if this solves your issue.

[palyamate]

It seems that my problem got solved with your new commits. Thank you for your quick reaction.