Information object set RANAP-ELEMENTARY-PROCEDURES is a union of
RANAP-ELEMENTARY-PROCEDURES-CLASS-1 and RANAP-ELEMENTARY-PROCEDURES-CLASS-2.
Each time _asn1f_assign_cell_value() parses an object, value of an
incremented counter is assigned to '_type_unique_index' field for
distinquishing different items.
However, these two information object sets have their own counters.
It has chance that generated variables have the same name and also the same
'_type_unique_index'. And they collide if they join up into one set.
S1AP's ASN.1 is lucky without this problem, while RANAP has.
By adding the number of items of the first set to '_type_unique_index' field
of items of the second set can solve this issue.
For example, there are many 'enum value_PR' and 'struct value' generated if
a class is instantiated as many instances.
typedef enum value_PR {
value_PR_NOTHING, /* No components present */
.....
} value_PR;
typedef struct ProtocolIE_Field_6563P5 {
....
struct value {
value_PR present;
union value_u {
} 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;
} ProtocolIE_Field_6563P5_t;
The aforementioned error message displayed during processing the following ASN.1 excerpt.
S1AP-ELEMENTARY-PROCEDURES S1AP-ELEMENTARY-PROCEDURE ::= {
S1AP-ELEMENTARY-PROCEDURES-CLASS-1 |
S1AP-ELEMENTARY-PROCEDURES-CLASS-2,
...
}
S1AP-ELEMENTARY-PROCEDURES-CLASS-1 S1AP-ELEMENTARY-PROCEDURE ::= {
handoverPreparation |
...
writeReplaceWarning,
...,
uERadioCapabilityMatch |
....
uEContextResume
}
S1AP-ELEMENTARY-PROCEDURES-CLASS-2 S1AP-ELEMENTARY-PROCEDURE ::= {
handoverNotification |
...
privateMessage,
...,
downlinkUEAssociatedLPPaTransport |
...
mMECPRelocationIndication
}
Because S1AP-ELEMENTARY-PROCEDURES-CLASS-1 and S1AP-ELEMENTARY-PROCEDURES-CLASS-2
are resolved 'after' S1AP-ELEMENTARY-PROCEDURES, so the ioc tables of them are not
available during resolving S1AP-ELEMENTARY-PROCEDURES. So we can not drop the
latter's containedSubtype field at first pass of asn1f_resolve_constraints of fix
process.
We also add second pass of asn1f_resolve_constraints to have a chance to combine
ioc tables of S1AP-ELEMENTARY-PROCEDURES-CLASS-1 and
S1AP-ELEMENTARY-PROCEDURES-CLASS-2.
This is a collection of works :
1. Based on @zhanglei002's pull request 99.
2. A fix by @AuthenticEshkinKot and merged by @mouse07410 at
commit 2c8d366bbe1fc4e4c041e9b0eb9779f8a42d754b of https://github.com/mouse07410/asn1c
to support parsing of Information Object and Information Object Set
3. A fix by @Uri Blumenthal in asn1fix_derefv.c at :
commit ec0ade4f87c807e763e3f35fc5466adb6dda3473 of https://github.com/mouse07410/asn1c
to solve crash on asn1p_value_free().
4. My pull request 18 to @mouse07410's https://github.com/mouse07410/asn1c to solve
problems found during parsing ASN.1 modules of S1AP, RANAP and J2735-201603.
5. My pull request 22 to @mouse07410's https://github.com/mouse07410/asn1c to solve issue 147
and to solve the problem during parsing ASN.1 module of NBAP.
6. My pull request 23 to @mouse07410's https://github.com/mouse07410/asn1c to fix memory leakage
introduced in aforementioned commits.
Most code changes are the same as pull request 153 to this repository.
7. A fix of my bug in item 6 which result asn1c crash, fixed by @mouse07410.
1. Add 'ref_cnt' field to asn1p_expr_t.
2. Initialize 'ref_cnt' field to zero when asn1p_expr_t is allocated.
3. Increase 'ref_cnt' field when asn1p_expr_t is cloned by asn1p_value_fromtype().
4. If 'ref_cnt' field of asn1p_expr_t is larger than zero, then asn1p_expr_free() only decrease its value.
5. Free memory pointed by fields of asn1p_expr_t and itself when 'ref_cnt' is zero and asn1p_expr_free() called.
6. Call asn1p_delete(asn) in main().
The function "free" is documented in the way that no action shall occur for
a passed null pointer. It is therefore not needed that a function caller
repeats a corresponding check.
http://stackoverflow.com/questions/18775608/free-a-null-pointer-anyway-or-check-first
This issue was fixed by using the software "Coccinelle 1.0.4".
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
The following functions return immediately if a null pointer was passed.
* asn1p_constraint_free
* asn1p_paramlist_free
* asn1p_ref_free
* asn1p_value_free
* asn1p_wsyntx_free
It is therefore not needed that a function caller repeats a corresponding check.
This issue was fixed by using the software "Coccinelle 1.0.4".
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Lev Walkin