Bionic Buffalo Tech Note #23: The France IDL Compiler: C Language Mapping
would not agree with that in the specification (without a release flag), and (2) the initial value of the
release flag might be indeterminate in the example. (Although uninitialized static variables can be
assumed to have a value of zero, that assumption is inappropriate for automatic variables. Note that,
while the C89 specification did not define initialization of automatic structures, the C99 specification
describes such initialization.)
Bionic Buffalo's conclusion is that the release flag must be implemented externally to the structures
themselves. Therefore, no
_release
member or similar item is created by the compiler. Note that
this practice differs from that of other implementations (such as ORBit, which uses a
CORBA_boolean _release
member), although such differences should make no difference as
long as only the specified
CORBA_*_release()
routines are used by applications.
There also is a potential portabilty problem with implementing the release flag as an additional
structure member, although it has not yet been seen in practice. On some rarely seen architectures, not
all pointers are the same size. (For example, on Univac 1100 hardware, byte addresses consist of word
addresses plus byte offsets, although a C compiler might simply use zero offsets for words and force
all C pointers to be the same size.) If the
_release
member were put at the beginning of the
structure, then the initialization example in the specification wouldn't work correctly. On the other
hand, on such machines (with varying-size pointers), putting the
_release
member at the end of the
structure representing a sequence would leave its offset unpredictable, since the sequence element type
isn't passed to
CORBA_sequence_get_release()
. There are ways around this, but they are
worse than the difficulties associated with keeping a release flag external to the sequence structure.
Bionic Buffalo's software, in implementing this decision, makes the assumption that release flags for
automatically and statically allocated sequence and
any
structures, initially
FALSE
, cannot be set
otherwise. This seems reasonable, in that the only reason for interrogating a release flag is to determine
if the secondary storage should be deallocated prior to deallocating the structure itself. In the case of
automatic and static structures, there is no reason to free them in the first place.
There is a line of thinking in some discussions that
CORBA_free()
ought to release secondary
storage automatically. We see no justification in the specification for this belief. Each secondary buffer
(string, sequence buffer, and so on) must be freed separately (by calling
CORBA_free()
, after
ascertaining that the release flag, if any, is
TRUE
.) (For convenience, the
yemen
library includes
functions to release (recursively) the storage of complex structures, given the structure's address and
TypeCode
.)
Generation of
TypeCode
Constants
The specification requires that an IDL compiler must be able to generate
TypeCode
constants for the
input definitions. Therefore, any IDL compiler is necessarily dependent on the implementation's form
of
TypeCode
s.
The definition of
TypeCode
structures for Bionic Buffalo's CORBA software is given in the
tibet
header files. Essentially, a
TypeCode
constant is implemented as a
void *
pointer, referencing a
Page 2 of 6