## 2 C IDL language mapping

### 2.1 Introduction

This chapter describes the mapping of OMG IDL constructs to the C programming language for the generation of native C - Erlang communication.

This language mapping defines the following:

- All OMG IDL basic types
- All OMG IDL constructed types
- References to constants defined in OMG IDL
- Invocations of operations, including passing of parameters and receiving of result
- Access to attributes

### 2.2 Mapping Pecularities

#### 2.2.1 Names Reserved by the Compiler

The IDL compiler reserves all identifiers starting with `OE_` and `oe_` for internal use.

#### 2.2.2 Scoped Names

The C programmer must always use the global name for a type, constant or operation. The C global name corresponding to an OMG IDL global name is derived by converting occurrences of "::" to underscore, and eliminating the leading "::". So, for example, an operation `op1` defined in interface `I1` which is defined in module `M1` would be written as `M1::I1::op1` in IDL and as `M1_I1_op1` in C.

| If underscores are used in IDL names it can lead to ambiguities due to the name mapping described above, therefore it is advisable to avoid the use of underscores in identifiers.

#### 2.2.3 Files

Two files will be generated for each scope. One set of files will be generated for each module and each interface scope. An extra set is generated for those definitions at top level scope. One of the files is a header file(`.h`), and the other file is a C source code file (`.c`). In addition to these files a number of C source files will be generated for type encodings, they are named according to the following template: `oe_code_<type>.c`.

For example:

    // IDL, in the file "spec.idl"
    module m1 {

        typedef sequence<long> lseq;

        interface i1 {
            ...
        };
        ...
    };

Will produce the files `oe_spec.h` and `oe_spec.c` for the top scope level. Then the files `m1.h` and `m1.c` for the module `m1` and files `m1_i1.h` and `m1_i1.c` for the interface `i1`. The typedef will produce `oe_code_m1_lseq.c`.

The header file contains type definitions for all `struct` types and sequences and constants in the IDL file. The c file contains all operation stubs if the the scope is an interface.

In addition to the scope-related files a C source file will be generated for encoding operations of all `struct` and sequence types.

### 2.3 Basic OMG IDL Types

The mapping of basic types is flexible to allow type adjustment. This can be used when porting to machines with different architectures.

OMG IDL Basic Types
OMG IDL type | C type | Implementation | Adjustable
float | CORBA_float | float | yes
double | CORBA_double | double | yes
short | CORBA_short | short | yes
unsigned short | CORBA_unsigned_short | unsigned short | yes
long | CORBA_long | long | yes
long long | CORBA_long_long | long | yes
unsigned long | CORBA_unsigned_long | unsigned long | yes
unsigned long long | CORBA_unsigned_long_long | unsigned long | yes
char | CORBA_char | char | yes
wchar | CORBA_wchar | unsigned long | yes
boolean | CORBA_boolean | unsigned char | yes
octet | CORBA_octet | char | yes
any | Not supported |  |
long double | Not supported |  |
Object | Not supported |  |
void | void | void | no

### 2.4 Constructed OMG IDL Types

Constructed types all have native mappings as shown in the list below.

#### 2.4.1 Mapping for String

OMG IDL strings are mapped to C CORBA_char*.

#### 2.4.2 Mapping for Wstring

OMG IDL wstrings are mapped to C CORBA_wchar*.

#### 2.4.3 Mapping for Struct

An OMG IDL structure is mapped directly onto a C struct.

#### 2.4.4 Mapping for Union

An OMG IDL union is mapped directly onto a C discriminated union.

#### 2.4.5 Mapping for Enum

An OMG IDL enum is directly mapped onto a C enum.

#### 2.4.6 Mapping for Sequence

OMG IDL sequences are mapped to a C struct that represents the sequence.

Consider the following IDL declaration:

    typedef sequence<long> lseq;

Which in C is represented as:

    typedef struct {
      CORBA_unsigned_long _maximum;
      CORBA_unsigned_long _length;
      CORBA_long* _buffer;
    } lseq;

#### 2.4.7 Mapping for Array

OMG IDL arrays are mapped directly to C arrays.

### 2.5 Mapping for Constants

Constants are mapped to C `#define`.

For example:

    // IDL
    module M1 {
        const long c1 = 99;
    };

Would result in the following define:

    #define M1_c1 99

### 2.6 Invocations of Operations

Operation invocation is achieved through a function call. The function calls have two default parameters, the interface object and the environment parameter. The result of the function is returned the usual way, while in and out parameters lie between the two default parameters in the same order as they appear in the IDL file.

Default parameters:

- < interface object > oe_obj - defined as CORBA_Object, always located as the first parameter of the operation. In the current implementation there is no use for this parameter.
- CORBA_Environment* oe_env - the environment structure. It is defined under ic.h and has the following public fields:
  - CORBA_Exception_type _major - will indicate whether the invocation terminated successfully, which will be one of the following:
    - CORBA_NO_EXCEPTION
    - CORBA_SYSTEM_EXCEPTION
  - int _fd - a file descriptor returned from erl_connect function.
  - int _inbufsz - size of input buffer.
  - char* _inbuf - pointer to a buffer used for input.
  - int _outbufsz - size of output buffer.
  - char* _outbuf - pointer to a buffer used for output.
  - int _memchunk - expansion unit size for the output buffer. This is the size of memory chunks in bytes used for increasing the output in case of buffer expansion. The value of this field must be allways set to >= 32, should be at least 1024 for performance reasons.
  - char regname[256] - a registered name for a process.
  - erlang_pid* _to_pid - an Erlang process identifier, is only used if the registered_name parameter is the empty string.
  - erlang_pid* _from_pid - your own process id so the answer can be returned
  Beside the public fields, other private fields are internally used but are not mentioned here.

Example:

    // IDL

    interface i1 {
        long op1(in long a);
        long op2(in string s, out long count);
    };

Is mapped to the following C functions

    // C

    CORBA_long i1_op1(i1 oe_obj, CORBA_long a, CORBA_Environment* oe_env)
    {
        ...
    }

    CORBA_long i1_op2(i1 oe_obj, CORBA_char* s, CORBA_long *count,
    CORBA_Environment* oe_env)
    {
        ...
    }

#### 2.6.1 Operation Implementation

There is no standard CORBA mapping for the C-server side, as it is implementation-dependent but built in a similar way. The current server side mapping is different from the client side mapping in several ways:

- Argument mappings
- Result values
- Structure
- Usage
- Exception handling

### 2.7 Exceptions

While exception mapping is not implemented, the stubs will generate CORBA system exceptions in case of operation failure. Thus, the only exceptions propagated by the system are built in system exceptions.

### 2.8 Access to Attributes

Not Supported

### 2.9 Summary of Argument/Result Passing for the C-client

The user-defined parameters can only be `in` or `out` parameters, as `inout` parameters are not supported.

This table summarize the types a client passes as arguments to a stub, and receives as a result.

Basic Argument and Result passing
OMG IDL type | In | Out | Return
short | CORBA_short | CORBA_short* | CORBA_short
long | CORBA_long | CORBA_long* | CORBA_long
long long | CORBA_long_long | CORBA_long_long* | CORBA_long_long
unsigned short | CORBA_unsigned_short | CORBA_unsigned_short* | CORBA_unsigned_short
unsigned long | CORBA_unsigned_long | CORBA_unsigned_long* | CORBA_unsigned_long
unsigned long long | CORBA_unsigned_long_long | CORBA_unsigned_long_long* | CORBA_unsigned_long_long
float | CORBA_float | CORBA_float* | CORBA_float
double | CORBA_double | CORBA_double* | CORBA_double
boolean | CORBA_boolean | CORBA_boolean* | CORBA_boolean
char | CORBA_char | CORBA_char* | CORBA_char
wchar | CORBA_wchar | CORBA_wchar* | CORBA_wchar
octet | CORBA_octet | CORBA_octet* | CORBA_octet
enum | CORBA_enum | CORBA_enum* | CORBA_enum
struct, fixed | struct* | struct* | struct
struct, variable | struct* | struct** | struct*
union, fixed | union* | union* | union
union, variable | union* | union** | union*
string | CORBA_char* | CORBA_char** | CORBA_char*
wstring | CORBA_wchar* | CORBA_wchar** | CORBA_wchar*
sequence | sequence* | sequence** | sequence*
array, fixed | array | array | array_slice*
array, variable | array | array_slice** | array_slice*

A client is responsible for providing storage of all arguments passed as in arguments.

Client argument storage responsibility
OMG IDL type | Out | Return
short | 1 | 1
long | 1 | 1
long long | 1 | 1
unsigned short | 1 | 1
unsigned long | 1 | 1
unsigned long long | 1 | 1
float | 1 | 1
double | 1 | 1
boolean | 1 | 1
char | 1 | 1
wchar | 1 | 1
octet | 1 | 1
enum | 1 | 1
struct, fixed | 1 | 1
struct, variable | 2 | 2
string | 2 | 2
wstring | 2 | 2
sequence | 2 | 2
array, fixed | 1 | 3
array, variable | 3 | 3

Argument passing cases
Case | Description
1 | Caller allocates all necessary storage, except that which may be encapsulated and managed within the parameter itself.
2 | The caller allocates a pointer and passes it by reference to the callee. The callee sets the pointer to point to a valid instance of the parameter's type. The caller is responsible for releasing the returned storage. Following completion of a request, the caller is not allowed to modify any values in the returned storage. To do so the caller must first copy the returned instance into a new instance, then modify the new instance.
3 | The caller allocates a pointer to an array slice which has all the same dimensions of the original array except the first, and passes it by reference to the callee. The callee sets the pointer to point to a valid instance of the array. The caller is responsible for releasing the returned storage. Following completion of a request, the caller is not allowed to modify any values in the returned storage. To do so the caller must first copy the returned instance into a new instance, then modify the new instance.

The returned storage in case 2 and 3 is allocated as one block of memory so it is possible to deallocate it with one call of CORBA_free.

### 2.10 Supported Memory Allocation Functions

- CORBA_Environment can be allocated from the user by calling CORBA_Environment_alloc().
  The interface for this function is
  `CORBA_Environment *CORBA_Environment_alloc(int inbufsz, int outbufsz);` where :
  - inbufsz is the desired size of input buffer
  - outbufsz is the desired size of output buffer
  - return value is a pointer to an allocated and initialized CORBA_Environment structure
- Strings can be allocated from the user by calling CORBA_string_alloc().
  The interface for this function is
  `CORBA_char *CORBA_string_alloc(CORBA_unsigned_long len);`
  where :
  - len is the length of the string to be allocated.

Thus far, no other type allocation function is supported.

### 2.11 Special Memory Deallocation Functions

- `void CORBA_free(void *storage)`
  This function will free storage allocated by the stub.
- `void CORBA_exception_free(CORBA_environment *ev)`
  This function will free storage allocated under exception propagation.

### 2.12 Exception Access Functions

- `CORBA_char *CORBA_exception_id(CORBA_Environment *ev)`
  This function will return raised exception identity.
- `void *CORBA_exception_value(CORBA_Environment *ev)`
  This function will return the value of a raised exception.

### 2.13 Special Types

- The erlang binary type has some special features.
  While the `erlang::binary` idl type has the same C-definition as a generated sequence of octets :

                module erlang
                {

                ....

                // an erlang binary
                typedef sequence<octet> binary;

                };

  it provides a way on sending trasparent data between C and Erlang.
  The C-definition (ic.h) for an erlang binary is :

                typedef struct {
                CORBA_unsigned_long _maximum;
                CORBA_unsigned_long _length;
                CORBA_octet* _buffer;
                } erlang_binary;                        /* ERLANG BINARY */

  The differences (between `erlang::binary` and `sequence< octet >`) are :
  - on the erlang side the user is sending/receiving typical built in erlang binaries, using `term_to_binary() / binary_to_term()` to create / extract binary structures.
  - no encoding/decoding functions are generated
  - the underlying protocol is more efficient than usual sequences of octets
  The erlang binary IDL type is defined in `erlang.idl`, while it's C definition is located in the `ic.h` header file, both in the `IC-< vsn >/include` directory. The user will have to include the file `erlang.idl` in order to use the `erlang::binary` type.

### 2.14 A Mapping Example

This is a small example of a simple stack. There are two operations on the stack, push and pop. The example shows all generated files as well as conceptual usage of the stack.

    // The source IDL file: stack.idl

    struct s {
          long l;
          string s;
    };

    interface stack {
        void push(in s val);
        s pop();
    };

When this file is compiled it produces four files, two for the top scope and two for the stack interface scope. The important parts of the generated C code for the stack API is shown below.

stack.c

    void push(stack oe_obj, s val, CORBA_Environment* oe_env) {
      ...
    }

    s* pop(stack oe_obj, CORBA_Environment* oe_env) {
      ...
    }

oe_stack.h

    #ifndef OE_STACK_H
    #define OE_STACK_H

    /*------------------------------------------------------------
     * Struct definition: s
     */
    typedef struct {
       long l;
       char *s;
    } s;

    #endif

stack.h just contains an include statement of `oe_stack.h`.

oe_code_s.c

    int oe_sizecalc_s(CORBA_Environment
          *oe_env, int* oe_size_count_index, int* oe_size) {
      ...
    }

    int oe_encode_s(CORBA_Environment *oe_env, s* oe_rec) {
      ...
    }

    int oe_decode_s(CORBA_Environment *oe_env, char *oe_first,
                    int* oe_outindex, s *oe_out) {
      ...
    }

The only files that are really important are the `.h` files and the stack.c file.

Copyright © 1991-2002 Ericsson Utvecklings AB