The build failures complain about misleading indentation:
../../../src/libasn1c/src/per_decoder.c:161:9: error: this 'if' clause does not guard... [-Werror=misleading-indentation]
161 | if(!td->aper_decoder)
| ^~
../../../src/libasn1c/src/per_decoder.c:163:17: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if'
163 | rval = td->aper_decoder(opt_codec_ctx, td, 0, sptr, &pd);
| ^~~~
Change-Id: I9ebd0de9135722bb718e2a5067f9b8238d0483dc
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).
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.
Neels Hofmeyr
Harald Welte