The warning appears again with GCC 12 in Debian 12, causing the build to
fail with --enable-werror. GCC 11 did not complain about it. As there
are numerous bug reports about this in GCC's bug tracker, just disable
it for all GCC versions.
Related: adaa1c62e1
Related: OS#6057
Change-Id: I48d9d423df47f23a0ef3ea727a40b53d70aec48b
GCC 10.2.1 20210110 from Debian 11 generates an invalid Warray-bounds
error. It was fixed in future GCC versions, I verified it with GCC
11.3.0. Ignore the warning, so we can build on Debian 11 with -Werror.
Fix for:
INTEGER.c: In function ‘asn_int642INTEGER’:
INTEGER.c:1340:34: error: array subscript 0 is outside array bounds of ‘int64_t[1]’ {aka ‘long int[1]’} [-Werror=array-bounds]
1340 | for(pstart = p, bp = buf, pend1 += add; p != pend1; p += add)
| ~~~~~~^~~~~~
INTEGER.c:1296:42: note: while referencing ‘value’
1296 | asn_int642INTEGER(INTEGER_t *st, int64_t value) {
| ~~~~~~~~^~~~~
Related: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
Change-Id: Ic10407e6d484ae29dc39edbdc6fcd0145e17e773
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.
Oliver Smith
Neels Hofmeyr
Harald Welte