@Go to the first, previous, ‰ŠP�”›next@�”˜, ‰ŠP�”›last@�”˜ section, ‰ŠP�”›table of contents@�”˜.
Œ

@dircategory GNU libraries @direntry * Libc: (libc). C library.
@shorttitlepage The GNU C Library Reference Manual The GNU C Library
Reference Manual
Sandra Loosemore with Richard M. Stallman, Roland McGrath, Andrew Oram, and Ulrich Drepper
Edition 0.07 DRAFT
last updated 4 Oct 1996
for version 2.00 Beta Copyright (C) 1993, '94, '95, '96, '97 Free Software Foundation, Inc.
Published by the Free Software Foundation
59 Temple Place -- Suite 330,
Boston, MA 02111-1307 USA
Printed copies are available for $50 each.
ISBN 1-882114-53-1

Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.
Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the section entitled "GNU Library General Public License" is included exactly as in the original, and provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.
Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that the text of the translation of the section entitled "GNU Library General Public License" must be approved for accuracy by the Foundation.
ˆ‰SEC1Št�”›Introduction

@�”˜The C language provides no built-in facilities for performing such common operations as input/output, memory management, string manipulation, and the like. Instead, these facilities are defined in a standard Blibrary@, which you compile and link with your programs. ‰IDX1Š
@�”˜The GNU C library, described in this document, defines all of the library functions that are specified by the ISO C standard, as well as additional features specific to POSIX and other derivatives of the Unix operating system, and extensions specific to the GNU system.
The purpose of this manual is to tell you how to use the facilities of the GNU library. We have mentioned which features belong to which standards to help you identify things that are potentially nonportable to other systems. But the emphasis in this manual is not on strict portability.
ˆ‰SEC2Št�”›Getting Started

@�”˜This manual is written with the assumption that you are at least somewhat familiar with the C programming language and basic programming concepts. Specifically, familiarity with ISO standard C (see section ‰ŠP�”›ISO C@�”˜), rather than "traditional" pre-ISO C dialects, is assumed.
The GNU C library includes several Bheader files@, each of which provides definitions and declarations for a group of related facilities; this information is used by the C compiler when processing your program. For example, the header file H`stdio.h'@ declares facilities for performing input and output, and the header file H`string.h'@ declares string processing utilities. The organization of this manual generally follows the same division as the header files.
If you are reading this manual for the first time, you should read all of the introductory material and skim the remaining chapters. There are a Blot@ of functions in the GNU C library and it's not realistic to expect that you will be able to remember exactly Bhow@ to use each and every one of them. It's more important to become generally familiar with the kinds of facilities that the library provides, so that when you are writing your programs you can recognize Bwhen@ to make use of library functions, and Bwhere@ in this manual you can find more specific information about them.
ˆ‰SEC3Št�”›Standards and Portability

‰IDX2Š
@�”˜This section discusses the various standards and other sources that the GNU C library is based upon. These sources include the ISO C and POSIX standards, and the System V and Berkeley Unix implementations.
The primary focus of this manual is to tell you how to make effective use of the GNU library facilities. But if you are concerned about making your programs compatible with these standards, or portable to operating systems other than GNU, this can affect how you use the library. This section gives you an overview of these standards, so that you will know what they are when they are mentioned in other parts of the manual.
See section ‰ŠP�”›Summary of Library Facilities@�”˜, for an alphabetical list of the functions and other symbols provided by the library. This list also states which standards each function or symbol comes from.
ˆ‰SEC4ŠT�”›ISO C

‰IDX3Š
@�”˜The GNU C library is compatible with the C standard adopted by the American National Standards Institute (ANSI): BAmerican National Standard X3.159-1989---"ANSI C"@ and later by the International Standardization Organization (ISO): BISO/IEC 9899:1990, "Programming languages--C"@. We here refer to the standard as ISO C since this is the more general standard in respect of ratification. The header files and library facilities that make up the GNU library are a superset of those specified by the ISO C standard.
‰IDX4Š@�”˜If you are concerned about strict adherence to the ISO C standard, you should use the H`-ansi'@ option when you compile your programs with the GNU C compiler. This tells the compiler to define Bonly@ ISO standard features from the library header files, unless you explicitly ask for additional features. See section ‰ŠP�”›Feature Test Macros@�”˜, for information on how to do this.
Being able to restrict the library to include only ISO C features is important because ISO C puts limitations on what names can be defined by the library implementation, and the GNU extensions don't fit these limitations. See section ‰ŠP�”›Reserved Names@�”˜, for more information about these restrictions.
This manual does not attempt to give you complete details on the differences between ISO C and older dialects. It gives advice on how to write programs to work portably under multiple C dialects, but does not aim for completeness.
ˆ‰SEC5ŠT�”›POSIX (The Portable Operating System Interface)

‰IDX5Š‰IDX6Š‰IDX7Š‰IDX8Š‰IDX9Š
@�”˜The GNU library is also compatible with the IEEE BPOSIX@ family of standards, known more formally as the BPortable Operating System Interface for Computer Environments@. POSIX is derived mostly from various versions of the Unix operating system.
The library facilities specified by the POSIX standards are a superset of those required by ISO C; POSIX specifies additional features for ISO C functions, as well as specifying new additional functions. In general, the additional requirements and functionality defined by the POSIX standards are aimed at providing lower-level support for a particular kind of operating system environment, rather than general programming language support which can run in many diverse operating system environments.
The GNU C library implements all of the functions specified in BIEEE Std 1003.1-1990, the POSIX System Application Program Interface@, commonly referred to as POSIX.1. The primary extensions to the ISO C facilities specified by this standard include file system interface primitives (see section ‰ŠP�”›File System Interface@�”˜), device-specific terminal control functions (see section ‰ŠP�”›Low-Level Terminal Interface@�”˜), and process control functions (see section ‰ŠP�”›Processes@�”˜).
Some facilities from BIEEE Std 1003.2-1992, the POSIX Shell and Utilities standard@ (POSIX.2) are also implemented in the GNU library. These include utilities for dealing with regular expressions and other pattern matching facilities (see section ‰ŠP�”›Pattern Matching@�”˜).
ˆ‰SEC6ŠT�”›Berkeley Unix

‰IDX10Š‰IDX11Š‰IDX12Š‰IDX13Š‰IDX14Š
@�”˜The GNU C library defines facilities from some versions of Unix which are not formally standardized, specifically from the 4.2 BSD, 4.3 BSD, and 4.4 BSD Unix systems (also known as BBerkeley Unix@) and from BSunOS@ (a popular 4.2 BSD derivative that includes some Unix System V functionality). These systems support most of the ISO C and POSIX facilities, and 4.4 BSD and newer releases of SunOS in fact support them all.
The BSD facilities include symbolic links (see section ‰ŠP�”›Symbolic Links@�”˜), the Hselect@ function (see section ‰ŠP�”›Waiting for Input or Output@�”˜), the BSD signal functions (see section ‰ŠP�”›BSD Signal Handling@�”˜), and sockets (see section ‰ŠP�”›Sockets@�”˜).
ˆ‰SEC7ŠT�”›SVID (The System V Interface Description)

‰IDX15Š‰IDX16Š‰IDX17Š
@�”˜The BSystem V Interface Description@ (SVID) is a document describing the AT&T Unix System V operating system. It is to some extent a superset of the POSIX standard (see section ‰ŠP�”›POSIX (The Portable Operating System Interface)@�”˜).
The GNU C library defines some of the facilities required by the SVID that are not also required by the ISO C or POSIX standards, for compatibility with System V Unix and other Unix systems (such as SunOS) which include these facilities. However, many of the more obscure and less generally useful facilities required by the SVID are not included. (In fact, Unix System V itself does not provide them all.)
ˆ‰SEC8Št�”›Using the Library

@�”˜This section describes some of the practical issues involved in using the GNU C library.
ˆ‰SEC9ŠT�”›Header Files

‰IDX18Š
@�”˜Libraries for use by C programs really consist of two parts: Bheader files@ that define types and macros and declare variables and functions; and the actual library or Barchive@ that contains the definitions of the variables and functions.
(Recall that in C, a Bdeclaration@ merely provides information that a function or variable exists and gives its type. For a function declaration, information about the types of its arguments might be provided as well. The purpose of declarations is to allow the compiler to correctly process references to the declared variables and functions. A Bdefinition@, on the other hand, actually allocates storage for a variable or says what a function does.) ‰IDX19Š‰IDX20Š
@�”˜In order to use the facilities in the GNU C library, you should be sure that your program source files include the appropriate header files. This is so that the compiler has declarations of these facilities available and can correctly process references to them. Once your program has been compiled, the linker resolves these references to the actual definitions provided in the archive file.
Header files are included into a program source file by the H`#include'@ preprocessor directive. The C language supports two forms of this directive; the first, #include "Bheader@"
is typically used to include a header file Bheader@ that you write yourself; this would contain definitions and declarations describing the interfaces between the different parts of your particular application. By contrast, #include <file.h>
is typically used to include a header file H`file.h'@ that contains definitions and declarations for a standard library. This file would normally be installed in a standard place by your system administrator. You should use this second form for the C library header files.
Typically, H`#include'@ directives are placed at the top of the C source file, before any other code. If you begin your source files with some comments explaining what the code in the file does (a good idea), put the H`#include'@ directives immediately afterwards, following the feature test macro definition (see section ‰ŠP�”›Feature Test Macros@�”˜).
For more information about the use of header files and H`#include'@ directives, see section `Header Files' in BThe GNU C Preprocessor Manual@.
The GNU C library provides several header files, each of which contains the type and macro definitions and variable and function declarations for a group of related facilities. This means that your programs may need to include several header files, depending on exactly which facilities you are using.
Some library header files include other library header files automatically. However, as a matter of programming style, you should not rely on this; it is better to explicitly include all the header files required for the library facilities you are using. The GNU C library header files have been written in such a way that it doesn't matter if a header file is accidentally included more than once; including a header file a second time has no effect. Likewise, if your program needs to include multiple header files, the order in which they are included doesn't matter.
DCompatibility Note:@ Inclusion of standard header files in any order and any number of times works in any ISO C implementation. However, this has traditionally not been the case in many older C implementations.
Strictly speaking, you don't Bhave to@ include a header file to use a function it declares; you could declare the function explicitly yourself, according to the specifications in this manual. But it is usually better to include the header file because it may define types and macros that are not otherwise available and because it may define more efficient macro replacements for some functions. It is also a sure way to have the correct declaration.
ˆ‰SEC10ŠT�”›Macro Definitions of Functions

‰IDX21Š‰IDX22Š‰IDX23Š
@�”˜If we describe something as a function in this manual, it may have a macro definition as well. This normally has no effect on how your program runs--the macro definition does the same thing as the function would. In particular, macro equivalents for library functions evaluate arguments exactly once, in the same way that a function call would. The main reason for these macro definitions is that sometimes they can produce an inline expansion that is considerably faster than an actual function call.
Taking the address of a library function works even if it is also defined as a macro. This is because, in this context, the name of the function isn't followed by the left parenthesis that is syntactically necessary to recognize a macro call.
You might occasionally want to avoid using the macro definition of a function--perhaps to make your program easier to debug. There are two ways you can do this: þÂ
• You can avoid a macro definition in a specific use by enclosing the name of the function in parentheses. This works because the name of the function doesn't appear in a syntactic context where it is recognizable as a macro call.
• You can suppress any macro definition for a whole source file by using the H`#undef'@ preprocessor directive, unless otherwise stated explicitly in the description of that facility.Àð
For example, suppose the header file H`stdlib.h'@ declares a function named Habs@ with extern int abs (int);
and also provides a macro definition for Habs@. Then, in: #include <stdlib.h>
int f (int *i) { return (abs (++*i)); }
the reference to Habs@ might refer to either a macro or a function. On the other hand, in each of the following examples the reference is to a function and not a macro. #include <stdlib.h>
int g (int *i) { return ((abs)(++*i)); }

#undef abs
int h (int *i) { return (abs (++*i)); }
Since macro definitions that double for a function behave in exactly the same way as the actual function version, there is usually no need for any of these methods. In fact, removing macro definitions usually just makes your program slower.
ˆ‰SEC11ŠT�”›Reserved Names

‰IDX24Š‰IDX25Š
@�”˜The names of all library types, macros, variables and functions that come from the ISO C standard are reserved unconditionally; your program Dmay not@ redefine these names. All other library names are reserved if your program explicitly includes the header file that defines or declares them. There are several reasons for these restrictions: þÂ
• Other people reading your code could get very confused if you were using a function named Hexit@ to do something completely different from what the standard Hexit@ function does, for example. Preventing this situation helps to make your programs easier to understand and contributes to modularity and maintainability.
• It avoids the possibility of a user accidentally redefining a library function that is called by other library functions. If redefinition were allowed, those other functions would not work properly.
• It allows the compiler to do whatever special optimizations it pleases on calls to these functions, without the possibility that they may have been redefined by the user. Some library facilities, such as those for dealing with variadic arguments (see section ‰ŠP�”›Variadic Functions@�”˜) and non-local exits (see section ‰ŠP�”›Non-Local Exits@�”˜), actually require a considerable amount of cooperation on the part of the C compiler, and implementationally it might be easier for the compiler to treat these as built-in parts of the language.Àð
In addition to the names documented in this manual, reserved names include all external identifiers (global functions and variables) that begin with an underscore (H`_'@) and all identifiers regardless of use that begin with either two underscores or an underscore followed by a capital letter are reserved names. This is so that the library and header files can define functions, variables, and macros for internal purposes without risk of conflict with names in user programs.
Some additional classes of identifier names are reserved for future extensions to the C language or the POSIX.1 environment. While using these names for your own purposes right now might not cause a problem, they do raise the possibility of conflict with future versions of the C or POSIX standards, so you should avoid these names. þÂ
• Names beginning with a capital H`E'@ followed a digit or uppercase letter may be used for additional error code names. See section ‰ŠP�”›Error Reporting@�”˜.
• Names that begin with either H`is'@ or H`to'@ followed by a lowercase letter may be used for additional character testing and conversion functions. See section ‰ŠP�”›Character Handling@�”˜.
• Names that begin with H`LC_'@ followed by an uppercase letter may be used for additional macros specifying locale attributes. See section ‰ŠP�”›Locales and Internationalization@�”˜.
• Names of all existing mathematics functions (see section ‰ŠP�”›Mathematics@�”˜) suffixed with H`f'@ or H`l'@ are reserved for corresponding functions that operate on Hfloat@ and Hlong double@ arguments, respectively.
• Names that begin with H`SIG'@ followed by an uppercase letter are reserved for additional signal names. See section ‰ŠP�”›Standard Signals@�”˜.
• Names that begin with H`SIG_'@ followed by an uppercase letter are reserved for additional signal actions. See section ‰ŠP�”›Basic Signal Handling@�”˜.
• Names beginning with H`str'@, H`mem'@, or H`wcs'@ followed by a lowercase letter are reserved for additional string and array functions. See section ‰ŠP�”›String and Array Utilities@�”˜.
• Names that end with H`_t'@ are reserved for additional type names.Àð
In addition, some individual header files reserve names beyond those that they actually define. You only need to worry about these restrictions if your program includes that particular header file. þÂ
• The header file H`dirent.h'@ reserves names prefixed with H`d_'@. ‰IDX26Š
• @�”˜The header file H`fcntl.h'@ reserves names prefixed with H`l_'@, H`F_'@, H`O_'@, and H`S_'@. ‰IDX27Š
• @�”˜The header file H`grp.h'@ reserves names prefixed with H`gr_'@. ‰IDX28Š
• @�”˜The header file H`limits.h'@ reserves names suffixed with H`_MAX'@. ‰IDX29Š
• @�”˜The header file H`pwd.h'@ reserves names prefixed with H`pw_'@. ‰IDX30Š
• @�”˜The header file H`signal.h'@ reserves names prefixed with H`sa_'@ and H`SA_'@. ‰IDX31Š
• @�”˜The header file H`sys/stat.h'@ reserves names prefixed with H`st_'@ and H`S_'@. ‰IDX32Š
• @�”˜The header file H`sys/times.h'@ reserves names prefixed with H`tms_'@. ‰IDX33Š
• @�”˜The header file H`termios.h'@ reserves names prefixed with H`c_'@, H`V'@, H`I'@, H`O'@, and H`TC'@; and names prefixed with H`B'@ followed by a digit. ‰IDX34ŠÀð
ˆ‰SEC12ŠT�”›Feature Test Macros

‰IDX35Š@�”˜The exact set of features available when you compile a source file is controlled by which Bfeature test macros@ you define.
If you compile your programs using H`gcc -ansi'@, you get only the ISO C library features, unless you explicitly request additional features by defining one or more of the feature macros. See section `GNU CC Command Options' in BThe GNU CC Manual@, for more information about GCC options.
You should define these macros by using H`#define'@ preprocessor directives at the top of your source code files. These directives Bmust@ come before any H#include@ of a system header file. It is best to make them the very first thing in the file, preceded only by comments. You could also use the H`-D'@ option to GCC, but it's better if you make the source files indicate their own meaning in a self-contained way.

AMacro:@ D_POSIX_SOURCE
Â‰IDX36Š@�”˜If you define this macro, then the functionality from the POSIX.1 standard (IEEE Standard 1003.1) is available, as well as all of the ISO C facilities.À

AMacro:@ D_POSIX_C_SOURCE
Â‰IDX37Š@�”˜If you define this macro with a value of H1@, then the functionality from the POSIX.1 standard (IEEE Standard 1003.1) is made available. If you define this macro with a value of H2@, then both the functionality from the POSIX.1 standard and the functionality from the POSIX.2 standard (IEEE Standard 1003.2) are made available. This is in addition to the ISO C facilities.À

AMacro:@ D_BSD_SOURCE
Â‰IDX38Š@�”˜If you define this macro, functionality derived from 4.3 BSD Unix is included as well as the ISO C, POSIX.1, and POSIX.2 material.
Some of the features derived from 4.3 BSD Unix conflict with the corresponding features specified by the POSIX.1 standard. If this macro is defined, the 4.3 BSD definitions take precedence over the POSIX definitions.
Due to the nature of some of the conflicts between 4.3 BSD and POSIX.1, you need to use a special BBSD compatibility library@ when linking programs compiled for BSD compatibility. This is because some functions must be defined in two different ways, one of them in the normal C library, and one of them in the compatibility library. If your program defines H_BSD_SOURCE@, you must give the option H`-lbsd-compat'@ to the compiler or linker when linking the program, to tell it to find functions in this special compatibility library before looking for them in the normal C library. ‰IDX39Š‰IDX40Š‰IDX41ŠÀ

A�”˜Macro:@ D_SVID_SOURCE
Â‰IDX42Š@�”˜If you define this macro, functionality derived from SVID is included as well as the ISO C, POSIX.1, POSIX.2, and X/Open material.À

AMacro:@ D_XOPEN_SOURCE
Â‰IDX43Š@�”˜If you define this macro, functionality described in the X/Open Portability Guide is included. This is a superset of the POSIX.1 and POSIX.2 functionality and in fact H_POSIX_SOURCE@ and H_POSIX_C_SOURCE@ are automatically defined.
As the unification of all Unices, functionality only available in BSD and SVID is also included.
If the macro H_XOPEN_SOURCE_EXTENDED@ is also defined, even more functionality is available. The extra functions will make all functions available which are necessary for the X/Open Unix brand.À

AMacro:@ D_GNU_SOURCE
Â‰IDX44Š@�”˜If you define this macro, everything is included: ISO C, POSIX.1, POSIX.2, BSD, SVID, X/Open, and GNU extensions. In the cases where POSIX.1 conflicts with BSD, the POSIX definitions take precedence.
If you want to get the full effect of H_GNU_SOURCE@ but make the BSD definitions take precedence over the POSIX definitions, use this sequence of definitions: #define _GNU_SOURCE
#define _BSD_SOURCE
#define _SVID_SOURCE
Note that if you do this, you must link your program with the BSD compatibility library by passing the H`-lbsd-compat'@ option to the compiler or linker. DNote:@ If you forget to do this, you may get very strange errors at run time.À

AMacro:@ D_REENTRANT
Â‰IDX45Š
ÀA�”˜Macro:@ D_THREAD_SAFE
Â‰IDX46Š@�”˜If you define one of these macros, reentrant versions of several functions get declared. Some of the functions are specified in POSIX.1c but many others are only available on a few other systems or are unique to GNU libc. The problem is that the standardization of the thread safe C library interface still is behind.
Unlike on some other systems no special version of the C library must be used for linking. There is only one version but while compiling this it must have been specified to compile as thread safe.À

We recommend you use H_GNU_SOURCE@ in new programs. If you don't specify the H`-ansi'@ option to GCC and don't define any of these macros explicitly, the effect is the same as defining H_POSIX_C_SOURCE@ to 2 and H_POSIX_SOURCE@, H_SVID_SOURCE@, and H_BSD_SOURCE@ to 1.
When you define a feature test macro to request a larger class of features, it is harmless to define in addition a feature test macro for a subset of those features. For example, if you define H_POSIX_C_SOURCE@, then defining H_POSIX_SOURCE@ as well has no effect. Likewise, if you define H_GNU_SOURCE@, then defining either H_POSIX_SOURCE@ or H_POSIX_C_SOURCE@ or H_SVID_SOURCE@ as well has no effect.
Note, however, that the features of H_BSD_SOURCE@ are not a subset of any of the other feature test macros supported. This is because it defines BSD features that take precedence over the POSIX features that are requested by the other macros. For this reason, defining H_BSD_SOURCE@ in addition to the other feature test macros does have an effect: it causes the BSD features to take priority over the conflicting POSIX features.
ˆ‰SEC13Št�”›Roadmap to the Manual

@�”˜Here is an overview of the contents of the remaining chapters of this manual. þÂ
• section ‰ŠP�”›Error Reporting@�”˜, describes how errors detected by the library are reported.
• section ‰ŠP�”›C Language Facilities in the Library@�”˜, contains information about library support for standard parts of the C language, including things like the Hsizeof@ operator and the symbolic constant HNULL@, how to write functions accepting variable numbers of arguments, and constants describing the ranges and other properties of the numerical types. There is also a simple debugging mechanism which allows you to put assertions in your code, and have diagnostic messages printed if the tests fail.
• section ‰ŠP�”›Memory Allocation@�”˜, describes the GNU library's facilities for dynamic allocation of storage. If you do not know in advance how much storage your program needs, you can allocate it dynamically instead, and manipulate it via pointers.
• section ‰ŠP�”›Character Handling@�”˜, contains information about character classification functions (such as Hisspace@) and functions for performing case conversion.
• section ‰ŠP�”›String and Array Utilities@�”˜, has descriptions of functions for manipulating strings (null-terminated character arrays) and general byte arrays, including operations such as copying and comparison.
• section ‰ŠP�”›Input/Output Overview@�”˜, gives an overall look at the input and output facilities in the library, and contains information about basic concepts such as file names.
• section ‰ŠP�”›Input/Output on Streams@�”˜, describes I/O operations involving streams (or HFILE *@ objects). These are the normal C library functions from H`stdio.h'@.
• section ‰ŠP�”›Low-Level Input/Output@�”˜, contains information about I/O operations on file descriptors. File descriptors are a lower-level mechanism specific to the Unix family of operating systems.
• section ‰ŠP�”›File System Interface@�”˜, has descriptions of operations on entire files, such as functions for deleting and renaming them and for creating new directories. This chapter also contains information about how you can access the attributes of a file, such as its owner and file protection modes.
• section ‰ŠP�”›Pipes and FIFOs@�”˜, contains information about simple interprocess communication mechanisms. Pipes allow communication between two related processes (such as between a parent and child), while FIFOs allow communication between processes sharing a common file system on the same machine.
• section ‰ŠP�”›Sockets@�”˜, describes a more complicated interprocess communication mechanism that allows processes running on different machines to communicate over a network. This chapter also contains information about Internet host addressing and how to use the system network databases.
• section ‰ŠP�”›Low-Level Terminal Interface@�”˜, describes how you can change the attributes of a terminal device. If you want to disable echo of characters typed by the user, for example, read this chapter.
• section ‰ŠP�”›Mathematics@�”˜, contains information about the math library functions. These include things like random-number generators and remainder functions on integers as well as the usual trigonometric and exponential functions on floating-point numbers.
• section ‰ŠP�”›Low-Level Arithmetic Functions@�”˜, describes functions for simple arithmetic, analysis of floating-point values, and reading numbers from strings.
• section ‰ŠP�”›Searching and Sorting@�”˜, contains information about functions for searching and sorting arrays. You can use these functions on any kind of array by providing an appropriate comparison function.
• section ‰ŠP�”›Pattern Matching@�”˜, presents functions for matching regular expressions and shell file name patterns, and for expanding words as the shell does.
• section ‰ŠP�”›Date and Time@�”˜, describes functions for measuring both calendar time and CPU time, as well as functions for setting alarms and timers.
• section ‰ŠP�”›Extended Characters@�”˜, contains information about manipulating characters and strings using character sets larger than will fit in the usual Hchar@ data type.
• section ‰ŠP�”›Locales and Internationalization@�”˜, describes how selecting a particular country or language affects the behavior of the library. For example, the locale affects collation sequences for strings and how monetary values are formatted.
• section ‰ŠP�”›Non-Local Exits@�”˜, contains descriptions of the Hsetjmp@ and Hlongjmp@ functions. These functions provide a facility for Hgoto@-like jumps which can jump from one function to another.
• section ‰ŠP�”›Signal Handling@�”˜, tells you all about signals--what they are, how to establish a handler that is called when a particular kind of signal is delivered, and how to prevent signals from arriving during critical sections of your program.
• section ‰ŠP�”›Process Startup and Termination@�”˜, tells how your programs can access their command-line arguments and environment variables.
• section ‰ŠP�”›Processes@�”˜, contains information about how to start new processes and run programs.
• section ‰ŠP�”›Job Control@�”˜, describes functions for manipulating process groups and the controlling terminal. This material is probably only of interest if you are writing a shell or other program which handles job control specially.
• section ‰ŠP�”›System Databases and Name Service Switch@�”˜, describes the services which are available for looking up names in the system databases, how to determine which service is used for which database, and how these services are implemented so that contributors can design their own services.
• section ‰ŠP�”›User Database@�”˜, and section ‰ŠP�”›Group Database@�”˜, tell you how to access the system user and group databases.
• section ‰ŠP�”›System Information@�”˜, describes functions for getting information about the hardware and software configuration your program is executing under.
• section ‰ŠP�”›System Configuration Parameters@�”˜, tells you how you can get information about various operating system limits. Most of these parameters are provided for compatibility with POSIX.
• section ‰ŠP�”›Summary of Library Facilities@�”˜, gives a summary of all the functions, variables, and macros in the library, with complete data types and function prototypes, and says what standard or system each is derived from.
• section ‰ŠP�”›Library Maintenance@�”˜, explains how to build and install the GNU C library on your system, how to report any bugs you might find, and how to add new functions or port the library to a new system.Àð
If you already know the name of the facility you are interested in, you can look it up in section ‰ŠP�”›Summary of Library Facilities@�”˜. This gives you a summary of its syntax and a pointer to where you can find a more detailed description. This appendix is particularly useful if you just want to verify the order and type of arguments to a function, for example. It also tells you what standard or system each function, variable, or macro is derived from.
Œ
Go to the first, previous, ‰ŠP�”›next@�”˜, ‰ŠP�”›last@�”˜ section, ‰ŠP�”›table of contents@�”˜.