Node and Host Name Sizes on HP-UX: Using the Expanded Capabilities of HP-UX

30
• For an array, pointer, or reference type, if the base type has an attached version identifier, the compiler
associates the same version identifier with the derived type.
• For a C++ pointer-to-member type, if either the class or the base type has an attached version identifier,
the compiler determines which of these version identifiers is lexically greater. It associates this high-
water mark as the version identifier for the type.
• For a typedef declaration, if the base type has an attached version identifier, the compiler associates
the same version identifier with the new type name.
• For a global variable declaration or definition, for a C++ namespace data member, or for a C++ class
static data member, if its type has an attached version identifier, the compiler records the version
identifier as part of the binary name for the variable.
• For a function declaration, definition, or function type, if its return type has an attached version
identifier, of if one or more of its parameter types have attached version identifiers, the compiler
determines which of these version identifiers is lexically greatest. It records the high-water mark as part
of the binary name for the function. For C++ nonstatic member functions, including constructors,
destructors, and operators, the compiler considers a version identifier attached to the class (because of
the implicit this pointer parameter).
• If a version identifier is directly applied to a declaration that also inherits a version identifier through the
above rules, the directly applied version identifier takes precedence, but it must not be lexically less than
the inherited one.
• When a name is redeclared in a source file, the following restrictions apply:
- If the first declaration has a version identifier, a subsequent declaration or definition must have
the identical version identifier.
- If the first declaration does not have a version identifier, a subsequent declaration or definition
must not have a version identifier.
To summarize, the rules state that any definition that includes some other definition inherits the version
from that other definition. Thus, a version identifier automatically becomes part of the binary name of
every interface affected by the changed type (as long as an explicit version identifier was applied to
that type). Also, when there are multiple version identifiers, the greatest one is inherited.
The inheritance of the version identifier means that developers need not explicitly apply version
attributes to each and every affected definition and declaration. It is sufficient to apply the version at
the point the change is made. This propagates to all affected interfaces.
Limitations of FLV
FLV does not manage every aspect of interface change because of some serious limitations. Due to
these limitations, FLV should be used only when absolutely necessary. It should be limited to a small
set of interfaces that are not extensively used. Other approaches should be exhausted before
resorting to FLV.
The following subsections describe limitations of FLV.
Constants Have No Version
Version identifiers cannot be applied to symbolic or literal constants. If a constant is used in the
definition of data structures or function parameters, the version attribute must be explicitly applied to
all those definitions.
Dynamic Library Loading: shl_findsym(), dlsym()
Utilities that reference the symbol table of an object or library do not have access to source names.
They have access only to the binary names. Thus, when looking up a function or data definition, the
binary name must be supplied.