One further RANAP hacking session
This is not development, it is random trial and error hacking. I really
hate the fact that we have no useful asn.1 code generator and need to
work with hacks like asn1tostruct.py and asn1c without information
object classes :/
This commit is a one-day-long iteration of trial+error, manually editing
and adding the .asn source of RANAP until we get something that in the
end at least compiles and links. Do I trust the resulting code? No.
But we have no alternative :(
diff --git a/src/ranap/RANAP_ProtocolIE-FieldPair.h b/src/ranap/RANAP_ProtocolIE-FieldPair.h
new file mode 100644
index 0000000..6a290e5
--- /dev/null
+++ b/src/ranap/RANAP_ProtocolIE-FieldPair.h
@@ -0,0 +1,43 @@
+/*
+ * Generated by asn1c-0.9.28 (http://lionet.info/asn1c)
+ * From ASN.1 module "RANAP-PDU"
+ * found in "../../asn1/ranap/RANAP-PDU.asn"
+ */
+
+#ifndef _RANAP_ProtocolIE_FieldPair_H_
+#define _RANAP_ProtocolIE_FieldPair_H_
+
+
+#include <asn_application.h>
+
+/* Including external dependencies */
+#include "RANAP_ProtocolIE-ID.h"
+#include "RANAP_Criticality.h"
+#include <ANY.h>
+#include <constr_SEQUENCE.h>
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/* RANAP_ProtocolIE-FieldPair */
+typedef struct RANAP_ProtocolIE_FieldPair {
+ RANAP_ProtocolIE_ID_t id;
+ RANAP_Criticality_t firstCriticality;
+ ANY_t firstValue;
+ RANAP_Criticality_t secondCriticality;
+ ANY_t secondValue;
+
+ /* Context for parsing across buffer boundaries */
+ asn_struct_ctx_t _asn_ctx;
+} RANAP_ProtocolIE_FieldPair_t;
+
+/* Implementation */
+extern asn_TYPE_descriptor_t asn_DEF_RANAP_ProtocolIE_FieldPair;
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RANAP_ProtocolIE_FieldPair_H_ */
+#include <asn_internal.h>