When JER was added it was based on XER, which has BASIC-XER and
CANONICAL-XER.
So originally we had BASIC-JER, which isn't a real thing.

This renames ATS_BASIC_JER to ATS_JER and adds JER in the list of
encodings in the readme.

For empty extensible SEQUENCE type, e.g.

  searchSpaceType              CHOICE {
    common                       SEQUENCE {
      dci-Format0-0-AndFormat1-0     SEQUENCE {
        ...
      }                                                           OPTIONAL,   -- Need R
      dci-Format2-0                SEQUENCE {
        nrofCandidates-SFI           SEQUENCE {
          aggregationLevel1            ENUMERATED {n1, n2}        OPTIONAL,   -- Need R
          aggregationLevel2            ENUMERATED {n1, n2}        OPTIONAL,   -- Need R
          aggregationLevel4            ENUMERATED {n1, n2}        OPTIONAL,   -- Need R
          aggregationLevel8            ENUMERATED {n1, n2}        OPTIONAL,   -- Need R
          aggregationLevel16           ENUMERATED {n1, n2}        OPTIONAL    -- Need R
        },
        ...
      }                                                         OPTIONAL,   -- Need R
      dci-Format2-1                SEQUENCE {
        ...
      }                                                         OPTIONAL,   -- Need R
      dci-Format2-2                SEQUENCE {
        ...
      }                                                         OPTIONAL,   -- Need R
      dci-Format2-3                SEQUENCE {
        dummy1                       ENUMERATED {sl1, sl2, sl4, sl5, sl8, sl10, sl16, sl20}    OPTIONAL,   -- Cond Setup
        dummy2                       ENUMERATED {n1, n2},
        ...
      }                                                         OPTIONAL    -- Need R
    },
    ue-Specific                    SEQUENCE {
      dci-Formats                    ENUMERATED {formats0-0-And-1-0, formats0-1-And-1-1},
      ...
    }
  }

According to X.691 :

  If the sequence type has an extension marker in the "ComponentTypeLists"
  or in the "SequenceType" productions, then a single bit shall first be added to
  the field-list in a bit-field of length one.

So for dci-Format0-0-AndFormat1-0, dci-Format2-1 and dci-Format2-2,
even they are empty without other fields, there shall be still one extension bit
to be added.

Use compute_extensions_start() to determine position of extension in
asn1c_lang_C_type_SEQUENCE_def() to fix this problem.

ProtocolExtensionField.c generated from the following excerpt from ASN.1 of F1AP v15.4.0 :

RRC-Version ::= SEQUENCE {
    latest-RRC-Version BIT STRING (SIZE(3)),
    iE-Extensions      ProtocolExtensionContainer { { RRC-Version-ExtIEs } } OPTIONAL}

RRC-Version-ExtIEs F1AP-PROTOCOL-EXTENSION ::= {
    {ID id-latest-RRC-Version-Enhanced CRITICALITY ignore EXTENSION OCTET STRING (SIZE(3)) PRESENCE optional },
    ...
}

failed to be compiled because asn_PER_memb_OCTET_STRING_SIZE_3__constr_31 is not generated.

The reason is constraints of types used in information object sets are not processed in asn1fix() stage
so it's constraint, i.e. (SIZE(3)) in this case, is not generated.

With this fix, OCTET STRING (SIZE(3)) used in ASN.1 of F1AP v15.4.0 can be correctly processed
and generated code can be compiled.

However, this fix does not work for all sorts of types.

For example, if information object refer to a type like this : SEQUENCE (SIZE(3)) OF INTEGER
it will be failed to compiled because asn_IOS_RRC_Version_ExtIEs_1_rows[] refers to non-existing
asn_DEF_SEQUENCE_OF.

This issue only occurred when ASN1C_PREFIX applies.

1. Modify asn1p_y.c and asn1p_y.y to fix an error that
   function _convert_bitstring2binary() always return NULL.

2. Add handling for default value with type ATV_BITVECTOR in
   function try_inline_default().

In LTE-RRC 36.331 15.3.0, there is :

    RLC-Config-NB-r13 ::= CHOICE {
        am    SEQUENCE {
            ul-AM-RLC-r13                UL-AM-RLC-NB-r13,
            dl-AM-RLC-r13                DL-AM-RLC-NB-r13
        },
        ...,
        [[  um-Bi-Directional-r15        NULL,
            um-Uni-Directional-UL-r15    NULL,
            um-Uni-Directional-DL-r15    NULL
        ]]
    }

that asn1c can not handle `[[` ... `]]` inside CHOICE type.

1. Modify asn1p_y.y and asn1p_y.c to mimic the approach for handling extension
   group inside SEQUENCE type.

2. Modify asn1c_C.c to use 'ext1', 'ext2' ... as extension groups names.

Because TAIItem and TAIList exist in NAGP-IEs module and NGAP-PDU
module, so name conflict condition occurs.

Previous returned value from asn1p_oid_compare() in asn1f_check_duplicate()
is incorrectly checked. Fix it by adding additional ASN1FIX flag
A1F_COMPOUND_NAMES which is set in asn1c.c.

In ASN.1 of 38.331 rev 15.2.1, module NR-InterNodeDefinitions
imports GapConfig from NR-RRC-Definition module. It should treat

  SetupRelease { GapConfig }

in module NR-InterNodeDefinitions the same as the one in
module NR-RRC-Definition.

For the following ASN.1 excerpt, the value of these Types will
be checked against its valid range in their corresponding
constraint functions.

DRB-Identity ::= INTEGER(1..32)
RSRP-Range   ::= INTEGER(0..97)
RSRQ-Range   ::= INTEGER(0..34)

Sometime it is convenient for application being aware of these
min and max values.

This commit generate the following macro defintions in
asn_constant.h :

\#define min_val_DRB_Identity (1)
\#define max_val_DRB_Identity (32)
\#define min_val_RSRP_Range (0)
\#define max_val_RSRP_Range (97)
\#define min_val_RSRQ_Range (0)
\#define max_val_RSRQ_Range (34)

The list of formats that are text output is a hardcoded list that didn't
include JER

This adds a `: ` between the type name and the data in SET OF

When ActualParameter to a parameterized type is a Type, commit
59b9e705 will produce C struct types using ActualParameter,
which are conflict with the C struct types for these Types themselves.

For example, the following typedef has duplicate definition of
UCI_OnPUSCH_t :

typedef struct UCI_OnPUSCH {
	UCI_OnPUSCH_PR present;
	union UCI_OnPUSCH_u {
		NULL_t	 release;
		UCI_OnPUSCH_t	 setup;
	} choice;

	/* Context for parsing across buffer boundaries */
	asn_struct_ctx_t _asn_ctx;
} UCI_OnPUSCH_t;

With this commit, if ActualParameter is a Type, then prefix it
with Parameterized Type name.

typedef struct SetupRelease_UCI_OnPUSCH {
	SetupRelease_UCI_OnPUSCH_PR present;
	union SetupRelease_UCI_OnPUSCH_u {
		NULL_t	 release;
		UCI_OnPUSCH_t	 setup;
	} choice;

	/* Context for parsing across buffer boundaries */
	asn_struct_ctx_t _asn_ctx;
} SetupRelease_UCI_OnPUSCH_t;

As for ActualParameter is ObjectSet, used in S1AP ... etc, it doesn't
prefix generated typedefs for keeping names shorter.

This commit can replace item 3 of

https://github.com/vlm/asn1c/issues/282#issuecomment-390838895

which solve part of #282.

1. Record the de-referenced expression to newly added field ref_expr
   of strcut asn1p_ref_t.
2. In function asn1c_make_identifier(), not only check whehter there
   is name clash occurred for this asn1p_expr_t but also the referenced
   expression to determine whether an additional module name to be added.
3. Change signature of some functions and variables to eliminate warning
   messages when const type pointer, i.e. const asn1p_ref_t *, variables
   versus, non-const * type pointer, i.e. asn1p_ref_t *, varibles are
   used. E.g.:
   warning: assignment discards ‘const’ qualifier from pointer target type

Recent commit abd1faa6 broke passing
already existing output decoded structre as sptr. As a result, a new
sptr was always allocated, and the old one leaked.

Fixes: abd1faa6

Should close #98

This should help aper_put_length() to take proper decisions on the way
to encode the length, since the range alone is not enough.
A contraint of lb=1 ub=65536 would yield a range=65536, but according to
ITU-T X.691 11.9 it shouldn't be encoded using nsnnwn since that only
applies in case ub<65536.
As a result, it would end up encoding/decoding it using 2 bytes while it
should use only 1.

Related: https://github.com/mouse07410/asn1c/issues/94

This should help aper_put_length() to take proper decisions on the way
to encode the length, since the range alone is not enough.
A contraint of lb=1 ub=65536 would yield a range=65536, but according to
ITU-T X.691 11.9 it shouldn't be encoded using nsnnwn since that only
applies in case ub<65536.
As a result, it would end up encoding/decoding it using 2 bytes while it
should use only 1.

Related: https://github.com/mouse07410/asn1c/issues/94

the code is in a version control system for this kind of reasons.

Fixed as seen the function is being called in most placed where
need_eom is true.

What's seems to be newish available ITU-T X.691 (02/2021),
has the related section at 11.9, not 10.9.

Drop spacing and use tabs everywhere.

This also fixes a gcc warning about "if" clause not guarding code below
it.

Fixes bug introduced in 0101252e [1].
This is actually mainly a revert of that commit.

That commit introduced a bug in which a small value (under 1 octet) with
range spanning full 2 octets (65536) was encoded incorrectly as 1 octet.

Section 4 of X.691 defines 64K as 65536, and Section 11.5.7 explicitly states
"""
c) "range" is greater than 256 and less than or equal to 64K (the two-octet case).
"""

This was noted while encoding SBc-AP messaged generated with asn1c,
where a SEQUENCE OF uses aper_put_length() to set the number of items.

[1] https://github.com/mouse07410/asn1c/pull/91

This commit adds a test case which shows a bug introduced in
0101252e [1].

As a result, a small value (under 1 octet) with range spanning full 2
octets (65536) is encoded incorrectly as 1 octet.

Section 4 of X.691 defines 64K as 65536, and Section 11.5.7 explicitly states
"""
c) "range" is greater than 256 and less than or equal to 64K (the two-octet case).
"""

[1] https://github.com/mouse07410/asn1c/pull/91

This patch introduces a test uncovering a bug when tyring to use
aper_put_length() with a value bigger than its range.
A follow up commit fixes the bug.

aper_put_length is expected to return the length being written in other
code paths. In the nsnnwn path, it was returning only 0 or <0.

While the historic asn1c code base has always had unit tests for not
just the ASN.1 parser but also the encoding rules, this doesn't seem
to hold true for the APER support in the various forks.

Unfortunately this has proven troublesome as over time patches were
merged supposedly fixing corner cases while in reality breaking behavior
that was perfectly in-line with the spec (ITU-T X.691).

Let's start by at least add some very basic coverage for the INTEGER
type in APER.

Otherwise the fields end up being misplaced and crash during encoding,
as can be seen in gdb:
"aper_decoder = 0x7ffff7687616 <OPEN_TYPE_encode_aper>, aper_encoder = 0x0"