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 is a side-effect of commit :

  939573d7 and
  dcc822a0

Which intends to solve the problem result from, e.g. for the following ASN.1 :

  HandoverRequestAcknowledge-IEs X2AP-PROTOCOL-IES ::= {
    { ID id-Old-eNB-UE-X2AP-ID  CRITICALITY ignore  TYPE UE-X2AP-ID  PRESENCE mandatory}|
    { ID id-New-eNB-UE-X2AP-ID  CRITICALITY ignore  TYPE UE-X2AP-ID  PRESENCE mandatory}|
    ...
  }

Items with id-Old-eNB-UE-X2AP-ID and id-New-eNB-UE-X2AP-ID are both of
type UE-X2AP-ID, so the generated enum type HandoverRequestAcknowledge_IEs__value_PR
will have two identical members :

  typedef enum HandoverRequestAcknowledge_IEs__value_PR {
      HandoverRequestAcknowledge_IEs__value_PR_NOTHING,    /* No components present */
      HandoverRequestAcknowledge_IEs__value_PR_UE_X2AP_ID,
      HandoverRequestAcknowledge_IEs__value_PR_UE_X2AP_ID,
      ...
  } HandoverRequestAcknowledge_IEs__value_PR

and the generated struc type HandoverRequestAcknowledge_IEs_t
will also have two identical members :

  typedef struct HandoverRequestAcknowledge_IEs {
      ProtocolIE_ID_t  id;
      Criticality_t    criticality;
      struct HandoverRequestAcknowledge_IEs__value {
          HandoverRequestAcknowledge_IEs__value_PR present;
          union XHandoverRequestAcknowledge_IEs__value_u {
              UE_X2AP_ID_t  UE_X2AP_ID;
              UE_X2AP_ID_t  UE_X2AP_ID;
              ...
          } choice;

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

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

these code excerpts results in compilation error.

Previous commits solve it by skipping duplicate items but raise
a side-effect that asn_MBR_HandoverRequestAcknowledge_IEs only has
one item corresponding UE_X2AP_ID field.

This commit rename the second item by adding '_2' (or said '_%d'
according to number of occurrence) to their names thus solve the
conflict.

This issue only occurred when ASN1C_PREFIX applies.

For the following examplified ASN.1,

  TEST DEFINITIONS AUTOMATIC TAGS ::=
  BEGIN

  S1 ::= SEQUENCE  {
    fn INTEGER,
    fb BIT STRING DEFAULT 'A5'H,
    fc OCTET STRING DEFAULT 'FFAABB'H
  }

  END

and input XER as :

  <S1>
    <fn>9845</fn>
    <fc>DEAD9</fc>
  </S1>

The encoded APER should be :

  S1 ::= {
    fn: 9845
    fb: A5
    fc: DE AD 90
  }

but current output is

  S1 ::= {
    fn: 9845
    fb: A5
    fc: FF AA BB
  }

The reason is in SEQUENCE_encode_aper(), default_value_cmp() are
incorrectly checked against 1.

If the input value is equal to default value, this return value from
compare function is 0.

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.

The function `SET_OF__encode_sorted` stored the working element buffer
in a static variable. If called recursively (that is, when performing
encoding of a SET containing another SET) the outermost element buffer
is therefore clobbered by the innermost call.

This causes a SEGV on continuation of the outermost call.

Bug found during testing of [https://github.com/surevine/spiffing Spiffing],
fix verified with the same test suite.

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)

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

Mimic what OAI's asnfix.c of generate_asn1 script does.

asn1c_save.c:238:5: error: this ‘for’ clause does not guard... [-Werror=misleading-indentation]
     for(int i = 0; i < argc; i++)
     ^~~
asn1c_save.c:240:2: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘for’
  safe_fprintf(mkf, "\n\n");
  ^~~~~~~~~~~~

../skeletons/INTEGER.c:510:60: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
             if(specs && specs->field_unsigned && dec_value <= ULONG_MAX) {

This fixes the following undefined behaviour

converter-example.c:721:13: runtime error: null pointer passed as argument 2, which is declared to never be null
/usr/include/string.h:44:28: note: nonnull attribute specified here

Previously some uper_* function were called

When there were no any padding bits the uper and aper decoders where
trying to read some which results in read past the buffer end.

See https://github.com/mouse07410/asn1c/issues/33#issuecomment-374625610

ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000315 at pc 0x000102ce9c15 bp 0x7fff5d20a8d0 sp 0x7fff5d20a8c8
READ of size 1 at 0x602000000315 thread T0
    #0 0x102ce9c14 in asn_get_few_bits asn_bit_data.c:132
    #1 0x102d878fd in aper_open_type_get_simple per_opentype.c:455
    #2 0x102d85dcc in aper_open_type_get per_opentype.c:514

On i686 the long is 4 bytes and when converted to uint64_t some big
unsigned values get converted to very big negative values

See https://github.com/vlm/asn1c/issues/185#issuecomment-372546490

On i686 the long is 4 bytes and the right shift with more then 32 bits
is probably an undefined behaviour

See https://github.com/vlm/asn1c/issues/185#issuecomment-372546490

Instead in two bytes the ENB-UE-S1AP-ID was encoded in three
For value 2 the correct encoding is `02 00 02 00`
and not `03 00 02 00 00`

And the MME-UE-S1AP-ID were encoded in 5 instead of 4

Files are from #185 and were renamed to match the Makefile's glob
pattern

bin/1.bin -> nextepc/sample-S1AP-PDU-1.aper

Thanks to @acetcom

Previously when decoding fails the memory was reset with memset after
casting the specifics to asn_CHOICE_specifics_t in order to get the size

The problem is that the OPEN TYPE could contains a different type not
derived from asn_CHOICE that does not have a struct_size member with a
valid size.

This fixes test failures in examples/sample.source.S1AP

This makes debugging and testing a lot more easier as skeleton files are
not copied and you don't need to execute `make regen` after every change
in the skeleton files.

You need to manually remove all skeleton files and run
`make regen-makefile` the first time after checking out this commit

Rename the existing files to match the glob used in the Makefile

To execute the tests run `make check` or `make check-aper`

and regenerate the the S1AP Makefile

According to Rec. ITU-T X.691 (08/2015)

11.5.3 Let "range" be defined as the integer value ("ub" – "lb" + 1), and let the value to be encoded be "n".

See also https://github.com/vlm/asn1c/issues/185#issuecomment-368745830

When generating code for multiple ASN.1 syntaxes that have clashing
names, we need to add a prefix in order to prevent clashes in the global
C symbol namespace.  Using the ASN1C_PREFIX environment variable and
this patch serves as a work-around to that.  All non-basic type names
as well as references to that type and source code + header file names
will be pre-fixed accordingly.

This is a re-implementation of this feature due to osmocom's
implementation version can not work on newest asn1c repository.