[erlang-questions] ASN.1 PER Does Not Correctly Handle Value Range Size Constraint
Tue May 24 04:51:34 CEST 2011
You are quite right about bit strings. I am not sure about SIZE OF. I
had missed the (SIZE(
This was a test I had written based on the following NBAP specification:
HARQ-MemoryPartitioningInfoExtForMIMO ::= SEQUENCE (SIZE (4|6|8)) OF
It is not a syntax error because ASN.1 grammar defines;
SEQUENCE Constraint OF Type
But, I agree this is a semantic error.
Thanks for clarifying this.
Kenneth Lundin wrote:
> You have spotted a weak point in the ASN.1 compiler but it is not the
> type of wrong behaviour as
> you think.
> For BIT STRING and SEQUENCE OF the standard defines that the following
> constraints are
> - Single value,
> - Contained Subtype
> - Size constraint
> But not Value-range
> On Sat, May 21, 2011 at 9:35 PM, Behdad Forghani
> <behdad.forghani@REDACTED> wrote:
>> I have tested this on R14B02.
>> I noticed that ASN.1 compiler does not handle value range size constraints
>> for SEQUENCE OF and BIT STRING.
>> For example:
>> Abs ::= BIT STRING(0|1|7)
> I don't know how to interpret Abs, what does it mean? i.e. the 0|1|7
> is it value 0, 1, 7? it is certainly not
> the size since then you have to write (SIZE(0|1|7))
>> Bbs ::= BIT STRING(3..18)
> This is a value range which is clearly not applicable (the compiler
> should have rejected this)
> If you want a SIZE constraint you should write BIT STRING (SIZE(3..18))
>> Cbs ::= BIT STRING
>> Abs has a size constraint of 0..7 and Bbs, 3..18.
> These are not size constraints they are value ranges. Which are not applicable.
> I have to check the standard regarding the union to see what it means
> for a BIT STRING if it is
> applicable at all.
>> All three of the above will be encoded identically as length indeterminant
>> as 0x07DA. This is only correct for Cbs. The problem seems to be that
>> encode_bit_string calls get_constraint(C,'SizeConstraint').
>> However the constraint for the Abs is a UNION and for Bbs a ValueRange. It
>> seems to me the support for both constraints needs to be added.
> No I don't think so. I think it should be added functionality to
> reject constraints which are not applicable for the type in question.
>> Just FYI, trying to give something back to the community. If I am correct, I
>> can easily fix it. In that case, can you enlighten me on how to submit my
>> code changes?
>> erlang-questions mailing list
> /Kenneth Erlang/OTP, Ericsson
More information about the erlang-questions