15.3.5 Pseudo-Object Types

   CORBA defines some kinds of entities that are neither primitive types (integral or floating point) nor constructed ones.

   15.3.5.1 TypeCode

   In general, TypeCodes are encoded as the TCKind enum value, potentially followed by values that represent the TypeCode parameters. Unfortunately, TypeCodes cannot be expressed simply in OMG IDL, since their definitions are recursive. The basic TypeCode representations are given in Table 15-2 on page 15-25. The integer value column of this table gives the TCKind enum value corresponding to the given TypeCode, and lists the parameters associated with such a TypeCode. The rest of this section presents the details of the encoding.

   Basic TypeCode Encoding Framework

   The encoding of a TypeCode is the TCKind enum value (encoded, like all enum values, using four octets), followed by zero or more parameter values. The encodings of the parameter lists fall into three general categories, and differ in order to conserve space and to support efficient traversal of the binary representation:

• Typecodes with an empty parameter list are encoded simply as the corresponding TCKind enum value.

• Typecodes with simple parameter lists are encoded as the TCKind enum value followed by the parameter value(s), encoded as indicated in Table 15-2. A “simple? parameter list has a fixed number of fixed length entries, or a single parameter that has its length encoded first.

• All other typecodes have complex parameter lists, which are encoded as the TCKind enum value followed by a CDR encapsulation octet sequence (see Section 15.3.3, “Encapsulation,? on page 15-14) containing the encapsulated, marshaled parameters. The order of these parameters is shown in the fourth column of Table 15-2.

    The third column of Table 15-2 shows whether each parameter list is empty, simple, or complex. Also, note that an internal indirection facility is needed to represent some kinds of typecodes; this is explained in “Indirection: Recursive and Repeated TypeCodes? on page 15-28. This indirection does not need to be exposed to application programmers.

   TypeCode Parameter Notation

    TypeCode parameters are specified in the fourth column of Table 15-2 on page 15-25. The ordering and meaning of parameters is a superset of those given in Section 4.11, “TypeCodes,? on page 4-53; more information is needed by CDR’s representation in order to provide the full semantics of TypeCodes as shown by the API.

• Each parameter is written in the form type (name), where type describes the parameter’s type, and name describes the parameter’s meaning.

• The encoding of some parameter lists (specifically, tk_struct, tk_union, tk_enum, and tk_except) contain a counted sequence of tuples.

   Such counted tuple sequences are written in the form count {parameters}, where count is the number of tuples in the encoded form, and the parameters enclosed in braces are available in each tuple instance. First the count, which is an unsigned long, and then each parameter in each tuple (using the noted type), is encoded in the CDR representation of the typecode. Each tuple is encoded, first parameter followed by second, before the next tuple is encoded (first, then second, etc.).

   Note that the tuples identifying struct, union, exception, and enum members must be in the order defined in the OMG IDL definition text. Also, that the types of discriminant values in encoded tk_union TypeCodes are established by the second encoded parameter (discriminant type), and cannot be specified except with reference to a specific OMG IDL definition.3

   3. This means that, for example, two OMG IDL unions that are textually equivalent, except that one uses a “char? discriminant, and the other uses a “long? one, would have different size encoded TypeCodes.

   Table 15-2TypeCode enum values, parameter list types, and parameters Table 15-2TypeCode enum values, parameter list types, and parameters Table 15-2TypeCode enum values, parameter list types, and parameters

1. The type of union label values is determined by the second parameter, discriminant type.

2. For unbounded strings, this value is zero.

3. For unbounded sequences, this value is zero.

4. Should be tk_null if there is no concrete base.

5. Should be tk_null if there is no concrete base.

6. See “Indirection: Recursive and Repeated TypeCodes? on page 15-28 .

   Encoded Identifiers and Names

   The Repository ID parameters in tk_objref, tk_struct, tk_union, tk_enum, tk_alias, tk_except, tk_native, tk_value, tk_value_box and tk_abstract_interface TypeCodes are Interface Repository RepositoryId values, whose format is described in the specification of the Interface Repository.

   For GIOP 1.2 onwards, repositoryID values are required to be sent, if known by the ORB4. For GIOP 1.2 and 1.3 an empty repositoryID string is only allowed if a repositoryID value is not available to the ORB sending the type code.

   For GIOP 1.0 and 1.1, RepositoryId values are required for tk_objref and tk_except TypeCodes; for tk_struct, tk_union, tk_enum, and tk_alias TypeCodes RepositoryIds are optional and encoded as empty strings if omitted.

   4. A type code passed via a GIOP 1.2 connection shall contain non-empty repositoryID strings, unless a repositoryID value is not available to the sending ORB for a specific type code. This situation can arise, for example, if an ORB receives a type code containing empty repository IDs via a GIOP 1.0 or 1.1 connection and passes that type code on via a GIOP 1.2 connection).

   The name parameters in tk_objref, tk_struct, tk_union, tk_enum, tk_alias, tk_value, tk_value_box, tk_abstract_interface, tk_native and tk_except TypeCodes and the member name parameters in tk_struct, tk_union, tk_enum, tk_value and tk_except TypeCodes are not specified by (or significant in) GIOP. Agents should not make assumptions about type equivalence based on these name values; only the structural information (including RepositoryId values, if provided) is significant. If provided, the strings should be the simple, unscoped names supplied in the OMG IDL definition text. If omitted, they are encoded as empty strings.

   When a reference to a base Object is encoded, there are two allowed encodings for the Repository ID: either "IDL:omg.org/CORBA/Object:1.0" or "" may be used.

   Encoding the tk_union Default Case

   In tk_union TypeCodes, the long default used value is used to indicate which tuple in the sequence describes the union’s default case. If this value is less than zero, then the union contains no default case. Otherwise, the value contains the zero-based index of the default case in the sequence of tuples describing union members.

   The discriminant value used in the actual typecode parameter associated with the default member position in the list, may be any valid value of the discriminant type, and has no semantic significance (i.e., it should be ignored and is only included for syntactic completeness of union type code marshaling).

   TypeCodes for Multi-Dimensional Arrays

   The tk_array TypeCode only describes a single dimension of any array. TypeCodes for multi-dimensional arrays are constructed by nesting tk_array TypeCodes within other tk_array TypeCodes, one per array dimension. The outermost (or top-level) tk_array TypeCode describes the leftmost array index of the array as defined in IDL; the innermost nested tk_array TypeCode describes the rightmost index.

   Indirection: Recursive and Repeated TypeCodes

   The typecode representation of OMG IDL data types that can indirectly contain instances of themselves (e.g., struct foo {sequence <foo> bar;}) must also contain an indirection. Such an indirection is also useful to reduce the size of encodings; for example, unions with many cases sharing the same value.

   CDR provides a constrained indirection to resolve this problem:

• The indirection applies only to TypeCodes nested within some “top-level? TypeCode. Indirected TypeCodes are not “freestanding,? but only exist inside some other encoded TypeCode.

• Only the second (and subsequent) references to a TypeCode in that scope may use the indirection facility. The first reference to that TypeCode must be encoded using the normal rules. In the case of a recursive TypeCode, this means that the first instance will not have been fully encoded before a second one must be completely encoded.

   The indirection is a numeric octet offset within the scope of the “top-level? TypeCode and points to the TCKind value for the typecode. (Note that the byte order of the TCKind value can be determined by its encoded value.) This indirection may well cross encapsulation boundaries, but this is not problematic because of the first constraint identified above. Because of the second constraint, the value of the offset will always be negative.

   Fragmentation support in GIOP versions 1.1, 1.2, and 1.3 introduces the possibility of a header for a FragmentMessage being marshaled between the target of an indirection and the start of the encapsulation containing the indirection. The octets occupied by any such headers are not included in the calculation of the offset value.

   The encoding of such an indirection is as a TypeCode with a “TCKind value? that has the special value 232-1 (0xffffffff, all ones). Such typecodes have a single (simple) parameter, which is the long offset (in units of octets) from the simple parameter. (This means that an offset of negative four (-4) is illegal because it will be selfindirecting.)

   15.3.5.2 Any

   Any values are encoded as a TypeCode (encoded as described above) followed by the encoded value. For Any values containing a tk_null or tk_void TypeCode, the encoded value shall have zero length (i.e., shall be absent).

   15.3.5.3 Principal

   Principal pseudo objects are encoded as sequence<octet>. In the absence of a Security service specification, Principal values have no standard format or interpretation, beyond serving to identify callers (and potential callers). This specification does not prescribe any usage of Principal values.

   By representing Principal values as sequence<octet>, GIOP guarantees that ORBs may use domain-specific principal identification schemes; such values undergo no translation or interpretation during transmission. This allows bridges to translate or interpret these identifiers as needed when forwarding requests between different security domains.

   15.3.5.4 Context

   Context pseudo objects are encoded as sequence<string>. The strings occur in pairs. The first string in each pair is the context property name, and the second string in each pair is the associated value. If an operation has an IDL context clause but the client does not supply any properties matching the context clause at run time, an empty sequence is marshaled.

   15.3.5.5 Exception

   Exceptions are encoded as a string followed by exception members, if any. The string contains the RepositoryId for the exception, as defined in the Interface Repository chapter. Exception members (if any) are encoded in the same manner as a struct.

   If an ORB receives a non-standard system exception that it does not support, or a user exception that is not defined as part of the operation's definition, the exception shall be mapped to UNKNOWN, with standard minor code set to 2 for a system exception, or set to 1 for a user exception.