NAME | DESCRIPTION | DEFINITIONS | MT-Level of Libraries | FILES | SEE ALSO | DIAGNOSTICS | NOTES ON MULTITHREADED APPLICATIONS | REALTIME APPLICATIONS | NOTES
This section describes functions found in various libraries, other than those functions that directly invoke UNIX system primitives, which are described in Section 2 of this volume. Function declarations can be obtained from the #include files indicated on each page. Certain major collections are identified by a letter after the section number:
These functions constitute the Source Compatibility (with BSD functions) library. It is implemented as a shared object, libucb.so, and as an archive, libucb.a, but is not automatically linked by the C compilation system. Specify -lucb on the cc command line to link with this library, which is located in the /usr/ucb subdirectory. Header files for this library are located within /usr/ucbinclude.
These functions, together with those of Section 2 and those marked (3S), constitute the standard C library, libc, which is automatically linked by the C compilation system. The standard C library is implemented as a shared object, libc.so, and as an archive, libc.a. C programs are linked with the shared object version of the standard C library by default. Specify -dn on the cc command line to link with the archive version. See libc(4), cc(1B) for other overrides, and the "C Compilation System" chapter of the ANSI C Programmer's Guide for a discussion. Some functions behave differently in standard-conforming environments. This behavior is noted on the individual manual pages. See standards(5).
These functions constitute the ELF access library, libelf, (Extensible Linking Formats). This library provides the interface for the creation and analyses of "elf" files; executables, objects, and shared objects. libelf is implemented as a shared object, libelf.so, and as an archive, libelf.a, but is not automatically linked by the C compilation system. Specify -lelf on the cc command line to link with this library. See libelf(4).
These functions constitute the string pattern-matching & pathname manipulation library, libgen. This library is implemented as an archive, libgen.a, but not as a shared object, and is not automatically linked by the C compilation system. Specify -lgen on the cc command line to link with this library.
These functions allow access to the kernel's virtual memory library, which is implemented as a shared object, libkvm.so, and as an archive, libkvm.a, but is not automatically linked by the C compilation system. Specify -lkvm on the cc command line to link with this library. See libkvm(4).
These functions constitute the math library, libm. This library is implemented as a shared object, libm.so, and as an archive, libm.a, but is not automatically linked by the C compilation system. Specify -lm on the cc command line to link with this library. See libmp(4).
These functions constitute the Network Service Library, libnsl. It is implemented as a shared object, libnsl.so, and as an archive, libnsl.a, but is not automatically linked by the C compilation system. Specify-lnsl on the cc command line to link with this library. See libnsl(4).
Some of the functions documented in man3n incorporate other network libraries, including:
libsocket (see libsocket(4)),
libresolv (see libresolv(4)),
librpcsvc (see librpcsvc(4)),
libnisdb (see libnisdb(4)),
librac (see librac(4)),
libxfn (see libxfn(4)), and
libkrb (see libkrb(4)).
Many base networking functions are also available in the X/Open Networking Interfaces library, libxnet. See section (3XN) below for more information on the libxnet interfaces.
Under all circumstances, the use of the Sockets API is recommended over the XTI and TLI APIs. If portability to other XPGV4v2 systems is a requirement, the application must use the libxnet interfaces. If portability is not required, the sockets interfaces in libsocket and libnsl are recommended over those in libxnet. Between the XTI and TLI APIs, the XTI interfaces (available with libxnet) are recommended over the TLI interfaces (available with libnsl).
These functions constitute the POSIX.4 Realtime library, libposix4. It is implemented only as a shared object, libposix4.so, and is not automatically linked by the C compilation system. Specify -lposix4 on the cc command line to link with this library. See libposix4(4).
These functions constitute the "standard I/O package" (see stdio(3S)). They can be compiled using the the standard C library, libc, which is automatically linked by the C compilation system. The standard C library is implemented as a shared object, libc.so, and as an archive, libc.a. See libc(4).
These functions constitute the threads libraries, libpthread and libthread. These libraries are used for building multithreaded applications. libpthread implements the POSIX (see standards(5)) threads interface, whereas libthread implements the Solaris threads interface.
Both POSIX threads and Solaris threads can be used within the same application. Their implementations are completely compatible with each other; however, only POSIX threads guarantee portability to other POSIX-conforming environments.
When POSIX and Solaris threads are used in the same application, if there are calls with the same name but different semantics, the POSIX semantic supersedes the Solaris threads semantic. For example, the call to fork() will imply the fork1() semantic in a program linked with the POSIX threads library, whether or not it is also linked with -lthread (Solaris threads).
The libpthread and libthread libraries are implemented as shared objects, libpthread.so and libthread.so, respectively, but not as archived libraries. libpthread and libthread are not automatically linked by the C compilation system. Specify -lpthread or -lthread on the cc command line to link with these libraries. See libpthread(4) and libthread(4).
The following functions are optional under POSIX and are not supported in the current Solaris release.
int pthread_mutexattr_setprotocol(pthread_mutexattr_t *attr, int protocol); int pthread_mutexattr_getprotocol(const pthread_mutexattr_t *attr, int *protocol); int pthread_mutexattr_setprioceiling(pthread_mutexattr_t *attr, int prioceiling); int pthread_mutexattr_getprioceiling(const pthread_mutexattr_t *attr, int *prioceiling);
Specialized libraries. These functions are contained in libraries including, but not limited to,
libadm (see libadm(4)),
libbsdmalloc,
libcrypt,
libcurses,
libdl (see libdl(4)),
libform,
libmail,
libmalloc,
libmapmalloc (see libmapmalloc(4)),
libmenu, and
libpanel.
These functions constitute the X/Open Curses library, located in /usr/xpg4/lib/libcurses.so.1. This library provides a set of internationalized functions and macros for creating and modifying input and output to a terminal screen. Included in this library are functions for creating windows, highlighting text, writing to the screen, reading from user input, and moving the cursor. X/Open Curses is designed to optimize screen update activities. The X/Open Curses library conforms fully with Issue 4 of the X/Open Extended Curses specification.
These functions constitute X/Open networking interfaces which comply with the X/Open CAE Specification, Networking Services, Issue 4 (September, 1994), and are located in /usr/lib/libxnet.so.1. See libxnet(4) and standards(5) for compilation information.
A character is any bit pattern able to fit into a byte on the machine.Exception: in some international languages, a "character" may require more than one byte, and is represented in multi-bytes.
The null character is a character with value 0, conventionally represented in the C language as \0. A character array is a sequence of characters. A null-terminated character array (a string) is a sequence of characters, the last of which is the null character. The null string is a character array containing only the terminating null character. A null pointer is the value that is obtained by casting 0 into a pointer. C guarantees that this value will not match that of any legitimate pointer, so many functions that return pointers return NULL to indicate an error. The macro NULL is defined in <stdio.h>. Types of the form size_t are defined in the appropriate headers.
See attributes(5) for descriptions of library MT-Levels.
usually /usr/include
usually /usr/ccs/lib
ar(1), cc(1B), ld(1), nm(1), fork(2), intro(2), stdio(3S), pthread_atfork(3T), libadm(4), libc(4), libelf( 4), libdl(4), libdrb(4), libkvm(4), libmapmalloc(4), libmp(4), libnisdb(4), libnsl(4), librac(4), libresolv(4), librpcsvc(4), libsocket(4), libpthread(4), libthread(4), libxfn(4), libxnet(4), attributes (5), standards(5)
Profiling Tools
ANSI C Programmer's Guide
For functions that return floating-point values, error handling varies according to compilation mode. Under the -Xt (default) option to cc, these functions return the conventional values 0, +-HUGE, or NaN when the function is undefined for the given arguments or when the value is not representable. In the -Xa and -Xc compilation modes, +-HUGE_VAL is returned in stead of +-HUGE. (HUGE_VAL and HUGE are defined in math.h to be infinity and the largest-magnitude single-precision number, respectively.)
When compiling a multithreaded application, either the _POSIX_C_SOURCE, _POSIX_PTHREAD_SEMANTICS, or _REENTRANT flag must be defined on the command line. This enables special definitions for functions only applicable to multithreaded applications. For POSIX.1c-conforming applications, define the _POSIX_C_SOURCE flag to be >= 199506L:
cc [flags] file... -D_POSIX_C_SOURCE=199506L -lpthread
For POSIX behavior with the Solaris fork() and fork1() distinction, compile as follows:
cc [flags] file... -D_POSIX_PTHREAD_SEMANTICS -lthread
For Solaris threads behavior, compile as follows:
cc [flags] file... -D_REENTRANT -lthread
When building a singlethreaded application, the above flags should be undefined. This generates a binary that is executable on previous Solaris releases, which do not support multithreading.
Unsafe interfaces should be called only from the main thread to ensure the application's safety.
MT-Safe interfaces are denoted in the ATTRIBUTES section of the functions and libraries manual pages (see attributes(5). If a manual page does not state explicitly that an interface is MT-Safe, the user should assume that the interface is unsafe.
Be sure to have set the environment variable LD_BIND_NOW to a non-null value to enable early binding. Refer to the "When Relocations are Processed" chapter inLinker and Libraries Guide for additional information.
None of the functions, external variables, or macros should be redefined in the user's programs. Any other name may be redefined without affecting the behavior of other library functions, but such redefinition may conflict with a declaration in an included header.
The headers in INCDIR provide function prototypes (function declarations including the types of arguments) for most of the functions listed in this manual. Function prototypes allow the compiler to check for correct usage of these functions in the user's program. The lint program checker may also be used and will report discrepancies even if the headers are not included with #include statements. Definitions for Sections 2, 3C, and 3S are checked automatically. Other definitions can be included by using the -l option to lint. (For example, -lm includes definitions for libm.) Use of lint is highly recommended. See the lint chapter in Performance Profiling Tools.
Users should carefully note the difference between STREAMS and stream. STREAMS is a set of kernel mechanisms that support the development of network services and data communication drivers. It is composed of utility routines, kernel facilities, and a set of data structures. A stream is a file with its associated buffering. It is declared to be a pointer to a type FILE defined in <stdio.h>.
In detailed definitions of components, it is sometimes necessary to refer to symbolic names that are implementation-specific, but which are not necessarily expected to be accessible to an application program. Many of these symbolic names describe boundary conditions and system limits.
In this section, for readability, these implementation-specific values are given symbolic names. These names always appear enclosed in curly brackets to distinguish them from symbolic names of other implementation-specific constants that are accessible to application programs by headers. These names are not necessarily accessible to an application program through a header, although they may be defined in the documentation for a particular system.
In general, a portable application program should not refer to these symbolic names in its code. For example, an application program would not be expected to test the length of an argument list given to a routine to determine if it was greater than {ARG_MAX}.
NAME | DESCRIPTION | DEFINITIONS | MT-Level of Libraries | FILES | SEE ALSO | DIAGNOSTICS | NOTES ON MULTITHREADED APPLICATIONS | REALTIME APPLICATIONS | NOTES