A few HS-DSCH conversations are created when calling add_hsdsch_bind,
such as when a RadioLinkReconfigurationPrepare procedure has
a id-HSDSCH-MACdFlows-to-Add element. This method should add
the CommunicationContextID to the conversation just like the
other ways of creating the conversation. This provides a UEID
for a unique key for RLC reassembly.
Clear the object_identifier_id global at the beginning of
each QCStatement, in case the statementId BER has errors and
does not put a value in the ptr. (call_ber_oid_callback correctly
handles being passed a NULL.)
Fix#18552.
This parameter was introduced as a safeguard for bugs
that generate an unbounded string but its utility for
that purpose is doubtful and the way it is being used
creates problems with invalid truncation of UTF-8
strings.
Rename wmem_strbuf_sized_new() with a better name.
Instead of using tvb_get_bits and proto_tree_add_uint,
use a bitmask in the field info and proto_tree_add_item.
This means that when epan/print.c writes PDML or JSON,
the value written is the correctly masked value (PDML also
includes the unmasked value.)
When proto_tree_add_uint is used, the value written to
PDML and JSON is the original value from the packet buffer,
not properly shifted.
Using a bitmask in the field definition allows us to use
proto_tree_add_item, which means that when print.c writes
PDML and JSON, the value written is the correctly masked
value (PDML also includes the unmasked value.)
When functions like proto_tree_add_uint are used instead,
the value written to PDML and JSON is the original value
from the packet buffer, not properly shifted.
Instead of using tvb_get_bits32 and proto_tree_add_uint,
use a bitmask in the field info and proto_tree_add_item.
This means that when epan/print.c writes PDML or JSON,
the value written is the correctly masked value (PDML also
includes the unmasked value.)
When proto_tree_add_uint is used, the value written to
PDML and JSON is the original value from the packet buffer,
not properly shifted.
The minimum and maximum length arguments to
dissect_per_constrained_set_of() are currently both ints.
According to O-RAN.WG3.E2AP-v02.03, section 9.3.7 "Constant
definitions", maxofRICrequestID is 1024, not 2^32-1; however, we were
specifying it as 2^32-1 (4294967295).
2^32-1 won't fit into an int, and Apple clang version 14.0.0
(clang-1400.0.29.102) warns about that:
./asn1/e2ap/e2ap.cnf:647:54: error: implicit conversion from 'long' to 'int' changes value from 4294967295 to -1 [-Werror,-Wconstant-conversion]
1, maxofRICrequestID, FALSE);
^~~~~~~~~~~~~~~~~
./asn1/e2ap/packet-e2ap-val.h:7:40: note: expanded from macro 'maxofRICrequestID'
#define maxofRICrequestID 4294967295
^~~~~~~~~~
The handling of MIN and MAX should be done with separate "minimum is
MIN" and "maximum is MAX" flags, and we might want either to have
asn2wrs.py reject attempts to have constraints with integer minimum and
maximum values outside the range [-2^31, 2^31-1], make the types for
sizes unsigned, or allow 64-bit constraints (and still limit the
constraint values, so we don't have to dive down a bignum rathole).
But, for now, we just change maxofRICrequestID to match what the 2022-10
version of the spec, 2.03, appears to say.
(I can't find the 2.01 version online, so I don't know whether it was
1024 in 2.01, or if it was changed in 2.02 or 2.03.)