background image
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