Unions Table Form Code Generation

If we now add table constraints to our original type definition, it might look as follows:

   Invoke ::= SEQUENCE {
      invokeID INTEGER,
      opcode OPERATION.&operationCode ({My-ops}),
      argument OPERATION.&ArgumentType ({My-ops}{@opcode})
   }

The “{My-ops}” constraint on the opcode element specifies an information object set that constrains the element value to one of the values in the object set. The {My-ops}{@opcode} constraint on the argument element goes a step further – it ties the type of the field to the type specified in the row that matches the given opcode value.

An example of the information object set and corresponding information objects would be as follows:

My-ops OPERATION ::= { makeCall | fwdCall, ... }

makeCall OPERATION ::= {
   &ArgumentType MakeCallArgument, 
   &operationCode local : 10
}

fwdCall OPERATION ::= {
   &ArgumentType FwdCallArgument, 
   &operationCode local : 11
}

The C or C++ type generated for the SEQUENCE above when –table-unions is specified would be as follows:

typedef struct EXTERN Invoke {
   OSINT32 invokeID;
   _OPERATION_operationCode opcode;
   struct {
      /**
       * information object selector
       */
      My_ops_TVALUE t;

      /**
       * My_ops information objects
       */
      union {
         /**
          * operationCode: local : 10
          */
         MakeCallArgument *makeCall;
         /**
          * operationCode: local : 11
          */
         FwdCallArgument *fwdCall;

         ASN1OpenType* extElem1;
      } u;
   } argument;
} Invoke;

            

Each of the options from the information object set are enumerated in the union structure. All a user needs to do to encode a variable of this type is to set the "t" value in the structure to the selected information object field and then populate the type field. This is very similar to populating a CHOICE construct. The comments in the elements show what the value of the key element(s) must be if that alternative is selected. The open type field at the end (extElem1) is added because the object set is extensible and it therefore may contain a value that is currently not included in the set.