IDL to C mapping

6 IDL to C mapping

6.1 Introduction

The IC C mapping (used by the C client and C server back-ends) follows the OMG C Language Mapping Specification.

The C mapping supports the following:

All OMG IDL basic types except long double and any.
All OMG IDL constructed types.
OMG IDL constants.
Operations with passing of parameters and receiving of results. inout parameters are not supported.

The following is not supported:

Access to attributes.
User defined exceptions.
User defined objects.

6.2 C Mapping Characteristics

6.2.1 Reserved Names

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

6.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.

Warning

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 underscores in identifiers.

6.2.3 Generated 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 {
        ...
    };
    ...
};

XXX This is C client specific. 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.

6.3 Basic OMG IDL Types

The mapping of basic types is as follows.

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

XXX Note that several mappings are not according to OMG C Language mapping.

6.4 Constructed OMG IDL Types

Constructed types have mappings as shown in the following table.

*OMG IDL Constructed Types*
OMG IDL type	Mapped to C type
string	CORBA_char*
wstring	CORBA_wchar*
struct	struct
union	union
enum	enum
sequence	struct (see below)
array	array

An OMG IDL sequence (an array of variable length),

// IDL
typedef sequence <IDL_TYPE> NAME;

is mapped to a C struct as follows:

/* C */
typedef struct {
  CORBA_unsigned_long _maximum;
  CORBA_unsigned_long _length;
  C_TYPE* _buffer;
} C_NAME;

where C_TYPE is the mapping of IDL_TYPE, and where C_NAME is the scoped name of NAME.

6.5 OMG IDL Constants

An IDL constant is mapped to a C constant through a C #define macro, where the name of the macro is scoped. Example:

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

results in the following:

/* C */
#define M1_c1 99

6.6 OMG IDL Operations

An OMG IDL operation is mapped to C function. Each C operation function has two mandatory parameters: a first parameter of interface object type, and a last parameter of environment type.

In a C operation function the the in and out parameters are located between the first and last parameters described above, and they appear in the same order as in the IDL operation declaration.

Notice that inout parameters are not supported.

The return value of an OMG IDL operation is mapped to a corresponding return value of the C operation function.

Mandatory C operation function parameters:

CORBA_Object oe_obj - the first parameter of a C operation function. This parameter is required by the OMG C Language Mapping Specification, but in the current implementation there is no particular use for it.
CORBA_Environment* oe_env - the last parameter of a C operation function. The parameter is defined in the C header file ic.h and has the following public fields:
- CORBA_Exception_type _major - indicates if an operation invocation was successful 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 always 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)
{
    ...
}

6.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

6.7 Exceptions

Although 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.

6.8 Access to Attributes

Not Supported

6.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.

6.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.

6.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.

6.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.

6.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.

6.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.