Failing to handle Unknown Extension

[zhouxt1]

Hi, I have found this potential issue when there are no defined extension items in the ASN.1 definition.

Follow this example,

SL-QoS-Profile-r16 ::=        SEQUENCE {
    sl-PQI-r16                    SL-PQI-r16                                                  OPTIONAL,   -- Need R
    sl-GFBR-r16                   INTEGER (0..4000000000)                                     OPTIONAL,   -- Need R
    sl-MFBR-r16                   INTEGER (0..4000000000)                                     OPTIONAL,   -- Need R
    sl-Range-r16                  INTEGER (1..1000)                                           OPTIONAL,   -- Need R
    ...
}

The corresponding code is

SRSASN_CODE sl_qos_profile_r16_s::unpack(cbit_ref& bref)
{
  bref.unpack(ext, 1);
  HANDLE_CODE(bref.unpack(sl_pqi_r16_present, 1));
  HANDLE_CODE(bref.unpack(sl_gfbr_r16_present, 1));
  HANDLE_CODE(bref.unpack(sl_mfbr_r16_present, 1));
  HANDLE_CODE(bref.unpack(sl_range_r16_present, 1));

  if (sl_pqi_r16_present) {
    HANDLE_CODE(sl_pqi_r16.unpack(bref));
  }
  if (sl_gfbr_r16_present) {
    HANDLE_CODE(unpack_integer(sl_gfbr_r16, bref, (uint32_t)0u, (uint32_t)4000000000u));
  }
  if (sl_mfbr_r16_present) {
    HANDLE_CODE(unpack_integer(sl_mfbr_r16, bref, (uint32_t)0u, (uint32_t)4000000000u));
  }
  if (sl_range_r16_present) {
    HANDLE_CODE(unpack_integer(sl_range_r16, bref, (uint16_t)1u, (uint16_t)1000u));
  }

  return SRSASN_SUCCESS;
}

However, it seems like even if the ext is parsed to True, there is no code that can handle the unknown extensions. It might be a more general case where most unknown extensions are not properly skipped. So the start bit position of the next message can be off.

Problem: This causes the bit string to be interpreted differently from how other ASN.1 parsers, such as asn1c, would parse it.