When decoding a constrained integer with a lower boundary, we need
to make sure the lower bound is added after decoding the raw offset
inside the range.
Before this change, RANAP_CauseMisc_unspecified_failure (115) would be
encoded as 2 (115 - 113 = 2), but would be decoded as 2, rather than
113+2 = 115.
Code for this was taken from
openairinterface5g/openair3/S1AP/MESSAGES/ASN1/asn1cpatch.p0 which
unfortunately doesn't carry much of a revision history :/
The number of bytes used by an APER encoded integer depends on its
actually encoded value, not on the maximum value that could be possibly
encoded.
The old code would e.g. always use 24 bits if the maximum encoded value
would require 24 bits.
To give an example RANAP MaxBitrate (INTEER 1 .. 16000000) value 64000
was previously encoded as "80 00 f9 ff", while it is now the correct
representation "40 f9 ff".
Thanks to Dieter Spaar for detecting this problem in the Osmo-IUH
generated RANAP output, and thanks to openairinterface for fixing the
bug in their code (sadly not contributed to upstream asn1c, though).
The libosmocore depedency is used for talloc and OSMO_ASSERT.
Reduce the depedencies by using libtalloc directly and replace
the ASSERT with a local one (without backtrace support).
When encoding an INTEGER, we need to subtract the lower bound before
encoding the value. This is specified in Clause 10.5.7.x of X.691.
The decoder already does this correct, but the encoder was wrong.
... which in turn causes all the ASN_DEBUG() to be turned into
fprintf(stderr, ...) statements, once the user application decides
to set 'asn_debug = 1' somewhere in its code.
The next step would be to make _ASN_DECODE_FAILED / _ASN_ENCODE_FAILED
no longer depend on ASN_DEBUG (which it currently does)
Sometimes, if the choice is a null or integer or ...
it's not easy to know what has really been selected without
the choice member name.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Harald Welte
Holger Hans Peter Freyther
Neels Hofmeyr
Daniel Willmann
Sylvain Munaut