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

Note that it does not have to be a system with the tunable expanded_node_host_names turned on

in order to build with this option or to run the resulting binary. However, the resulting binary might be

able to execute correctly only if HP-UX 11i v2 September 2004 Update or higher is installed, as that

update contains the expanded programming interfaces. Furthermore, if the program does not use

node-name related symbols (that is, if it uses only host-name related symbols), it can also execute

correctly on the original HP-UX 11i v2 2003 version. However, if you want to execute on the original

HP-UX 11i v2, it is best to use the technique described in “Building for Execution on Multiple

Releases.”.

Note also that enhancing programs to use the expanded utsname structure and uname(2) system

function prepares them to handle future value expansion for any other fields in that structure.

Behavior of Existing Interfaces

The interfaces used to obtain the node and host names are uname() and gethostname(),

respectively.

In the case of uname(), an application that has not been updated to use the expanded version of the

function will be using a version of the associated utsname structure which has a nodename field of 9

bytes (for 8 byte node name and a terminating null byte). In an environment where the system’s node

name has been set to more than 8 bytes, the program either gets an EOVERFLOW error or receives

only the first 8 bytes of that name. The reporting of the EOVERFLOW error is activated or suppressed

by the uname_eoverflow system tunable parameter.

Caution: On HP-UX 11i v2 an error status is not returned to indicate that the truncation has occurred.

The lack of an error return on truncation occurs because many programs use the uname() function for

data other than the node name, or can easily tolerate using the truncated value. This changed in 11i

v3, so that applications are notified of the incomplete data as soon as possible.

In the case of gethostname(), the returned string length is limited to the size provided as the

second parameter. Many programs allocate buffers using the symbolic constant MAXHOSTNAMELEN

(although it is important to note that some use smaller constants). For the default compilation

environment, its value is 64. Adding-D_HPUX_API_LEVEL=20040821 to the compilation

environment changes its value to 256, thus accommodating larger host names. For programs that

are not recompiled and run on a system with a host name longer than 64 bytes, only the first 64 bytes

will be returned. No error status is provided because the standard specifications state that the

returned name shall be truncated if the supplied buffer is of insufficient length. On HP-UX, the lack of

a terminating null byte in the buffer indicates that the name might not be complete.

Source Code Issues and Fixes

In the vast majority of cases, compiling as described in the preceding section makes the program long

node and host name clean. However, problem areas might exist in some programs that need source

code corrections. For the most part, these problems stem from code that does not use the interfaces

as specified. That is, latent bugs might be exposed by the expanded node and host name interfaces.

No field value other than utsname.nodename is expanded for the initial release of HP-UX11i V3. While there are no

plans for the near future, it is possible that other values in that structure will be expanded in an update or succeeding release.