3 C IDL language mapping
3.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
3.2 Mapping pecularities
3.2.1 Names reserved by the compiler
The IDL compiler reserves all identifiers starting with
OE_
andoe_
for internal use.3.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 interfaceI1
which is defined in moduleM1
would be written asM1::I1::op1
in IDL and asM1_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.
3.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
andoe_spec.c
for the top scope level. Then the filesm1.h
andm1.c
for the modulem1
and filesm1_i1.h
andm1_i1.c
for the interfacei1
. The typedef will produceoe_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.3.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 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 unsigned long CORBA_unsigned_long unsigned long yes char CORBA_char char yes boolean CORBA_boolean unsigned char yes octet CORBA_octet char yes any Not supported Object Not supported void void void no OMG IDL basic types 3.4 Constructed OMG IDL types
Constructed types all have native mappings as shown in the table below.
3.4.1 Mapping for string
OMG IDL strings are mapped to C CORBA_char*.
3.4.2 Mapping for struct
An OMG IDL structure is mapped directly onto a C struct.
3.4.3 Mapping for union
3.4.4 Mapping for enum
An OMG IDL enum is directly mapped onto a C enum.
3.4.5 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 { int size; CORBA_long* buf; } lseq;3.4.6 Mapping for array
OMG IDL arrays are mapped directly to C arrays.
3.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 993.6 Invocations of operations
Operation invocation is achieved through a function call. The function calls have two default parameters, the
interface object
and theenvironment
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 underic.h
and has the following public fields:Beside the public fields, other, private fields are internally used but not mentioned here.
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 fromerl_connect
.char* _inbuf
- pointer to a buffer used for input.int _inbufsz
- maximum size of input buffer..char* _outbuf
- pointer to a buffer used for output.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
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) { ... }3.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 than the client side mapping in several ways:
- Argument mappings.
- Result values.
- Structure.
- Usage.
- Exception handling.
3.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 build in system exceptions.
3.8 Access to attributes
3.9 Summary of argument/result passing for the C-client
The user defined parameters can only be
in
orout
parameters, asinout
parameters are not supported.This table summarize the types a client passes as arguments to a stub and receives as a result.
OMG IDL type In Out Return short CORBA_short CORBA_short* CORBA_short long CORBA_long CORBA_long* CORBA_long unsigned short CORBA_unsigned_short CORBA_unsigned_short* CORBA_unsigned_short unsigned long CORBA_unsigned_long CORBA_unsigned_long* CORBA_unsigned_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 octet CORBA_octet CORBA_octet* CORBA_octet enum CORBA_enum CORBA_enum* CORBA_enum struct, fixed struct* struct* struct struct, variable struct* struct** struct* string CORBA_char* CORBA_char** CORBA_char* sequence sequence* sequence** sequence* array, fixed array array array_slice* array, variable array array_slice** array_slice* Basic Argument and Result passing A client is responsible for providing storage of all arguments passed as in arguments.
OMG IDL type Out Return short 1 1 long 1 1 unsigned short 1 1 unsigned long 1 1 float 1 1 double 1 1 boolean 1 1 char 1 1 octet 1 1 enum 1 1 struct, fixed 1 1 struct, variable 2 2 string 2 2 sequence 2 2 array, fixed 1 3 array, variable 3 3 Client argument storage responsibility
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 modified 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 modified 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. Argument passing cases The returned storage in case 2 and 3 is allocated as one block of memory so it's possible to deallocate it with one call of CORBA_free.
3.10 Supported memory allocation functions
- 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);
Thus far, no other type allocation function is supported.
3.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.
3.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.
3.13 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; #endifstack.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.