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

APPENDIX D: FLV Concepts and Usage

Function-Level Versioning (FLV) is a feature of the HP-UX compiler and linker that assists in the

management of changes to interfaces. It provides the capability to define and export multiple

versions of a function or data interface. To ensure correct operation, client references to the interfaces

are bound to the desired version at link time.

HP-UX 11i v2 September 2004 Update, as well as later updates and releases, utilize this mechanism

to provide two versions of the uname() function and, correspondingly, two versions of the associated

utsname structure definition. The version used is selected during compilation.

In general, application code need not be aware of the two versions. The default compilation

environment selects the version that is compatible with prior versions of HP-UX. To select the version

that supports expanded node and host names, the option

–D_HPUX_API_LEVEL=20040821 is included in the compilation environment.

This appendix describes how the FLV feature works, how it implicitly affects interfaces that re-export

versioned interfaces, how it is used for node names, and where it might need to be explicitly

employed by library providers.

Caution: FLV is available for updating a small set of interfaces that are not extensively used. The

feature has limitations that makes its widespread use ill advised. Its primary purpose is to enable HP

to expand interfaces without requiring recompilation of applications. It is described here primarily

for the benefit of developers whose interfaces re-export the node and host name-related interfaces.

HP does not support use of FLV for other purposes.

Elements of FLV

This section describes the mechanisms and syntax of FLV.

A Simple Example

For the purposes of illustration, suppose the following interface has been defined for some time:

void logevent(struct eventinfo *evp);

The interface provides a general service used by many clients. However, because of the demands of

the user community, a second parameter needs to be added. The interface is updated as follows:

void logevent(struct eventinfo *evp, void *eventdata);

This pleases the users who were demanding the enhancement. However, it creates problems for the

users who have no need to provide data with the event. These users must add a second parameter,

usually NULL. Worse, other users who are unaware of the change might re-link their application to

the enhanced interface without having updated the source code. This can cause indeterminate

behavior when logevent() attempts to de-reference the pointer that was not provided.

The interface providers might have been able to instead add a second logevent_rev2() interface

to accept two parameters and leave the existing one alone. Defining a second name is preferred

over using FLV. However, the change might have been dictated by revisions to standard

specifications. A second name may not be acceptable (as is the case with uname() on HP-UX.)