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 library, which you compile and link with your
programs.

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 non-portable
to other systems. But the emphasis in this manual is not on strict
portability.

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 ISO C), rather than "traditional" pre-ISO C dialects, is
assumed.

The GNU C library includes several header 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 `stdio.h' declares facilities for
performing input and output, and the header file `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 lot of functions in the GNU C library and it's not realistic to
expect that you will be able to remember exactly how 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 when to make use of
library functions, and where in this manual you can find more
specific information about them.

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 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.

The GNU C library is compatible with the C standard adopted by the
American National Standards Institute (ANSI):
American National Standard X3.159-1989---"ANSI C" and later
by the International Standardization Organization (ISO):
ISO/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.

If you are concerned about strict adherence to the ISO C standard, you
should use the `-ansi' option when you compile your programs with
the GNU C compiler. This tells the compiler to define only ISO
standard features from the library header files, unless you explicitly
ask for additional features. See section 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 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.

The GNU library is also compatible with the ISO POSIX family of
standards, known more formally as the Portable Operating System
Interface for Computer Environments (ISO/IEC 9945). They were also
published as ANSI/IEEE Std 1003. 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
ISO/IEC 9945-1:1996, 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 File System Interface), device-specific
terminal control functions (see section Low-Level Terminal Interface), and
process control functions (see section Processes).

Some facilities from ISO/IEC 9945-2:1993, 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 Pattern Matching).

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 Berkeley Unix) and from
SunOS (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 GNU C library defines most 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.)

The supported facilities from System V include the methods for
inter-process communication and shared memory, the hsearch and
drand48 families of functions, fmtmsg and several of the
mathematical functions.

The X/Open Portability Guide, published by the X/Open Company, Ltd., is
a more general standard than POSIX. X/Open owns the Unix copyright and
the XPG specifies the requirements for systems which are intended to be
a Unix system.

The GNU C library complies to the X/Open Portability Guide, Issue 4.2,
with all extensions common to XSI (X/Open System Interface)
compliant systems and also all X/Open UNIX extensions.

The additions on top of POSIX are mainly derived from functionality
available in System V and BSD systems. Some of the really bad
mistakes in System V systems were corrected, though. Since
fulfilling the XPG standard with the Unix extensions is a
precondition for getting the Unix brand chances are good that the
functionality is available on commercial systems.

Libraries for use by C programs really consist of two parts: header
files that define types and macros and declare variables and
functions; and the actual library or archive that contains the
definitions of the variables and functions.

(Recall that in C, a declaration 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 definition, on the other hand, actually allocates storage for a
variable or says what a function does.)

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
`#include' preprocessor directive. The C language supports two
forms of this directive; the first,

#include "header"

is typically used to include a header file header 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 `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, `#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 `#include' directives immediately afterwards, following the
feature test macro definition (see section Feature Test Macros).

For more information about the use of header files and `#include'
directives, see section `Header Files' in The 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.

Compatibility 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 have 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.

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 `#undef' preprocessor directive, unless otherwise stated
explicitly in the description of that facility.

For example, suppose the header file `stdlib.h' declares a function
named abs with

extern int abs (int);

and also provides a macro definition for abs. Then, in:

#include <stdlib.h>
int f (int *i) { return abs (++*i); }

the reference to abs 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.

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.

The names of all library types, macros, variables and functions that
come from the ISO C standard are reserved unconditionally; your program
may 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 exit to do something completely different from
what the standard exit 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 Variadic Functions)
and non-local exits (see section 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 (`_') 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 `E' followed a digit or uppercase
letter may be used for additional error code names. See section Error Reporting.

Names that begin with either `is' or `to' followed by a
lowercase letter may be used for additional character testing and
conversion functions. See section Character Handling.

Names that begin with `LC_' followed by an uppercase letter may be
used for additional macros specifying locale attributes.
See section Locales and Internationalization.

Names of all existing mathematics functions (see section Mathematics)
suffixed with `f' or `l' are reserved for corresponding
functions that operate on float and long double arguments,
respectively.

Names that begin with `SIG' followed by an uppercase letter are
reserved for additional signal names. See section Standard Signals.

Names that begin with `SIG_' followed by an uppercase letter are
reserved for additional signal actions. See section Basic Signal Handling.

Names beginning with `str', `mem', or `wcs' followed by a
lowercase letter are reserved for additional string and array functions.
See section String and Array Utilities.

Names that end with `_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 exact set of features available when you compile a source file
is controlled by which feature test macros you define.

If you compile your programs using `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 The GNU CC Manual,
for more information about GCC options.

You should define these macros by using `#define' preprocessor
directives at the top of your source code files. These directives
must come before any #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 `-D' option to GCC, but it's
better if you make the source files indicate their own meaning in a
self-contained way.

This system exists to allow the library to conform to multiple standards.
Although the different standards are often described as supersets of each
other, they are usually incompatible because larger standards require
functions with names that smaller ones reserve to the user program. This
is not mere pedantry -- it has been a problem in practice. For instance,
some non-GNU programs define functions named getline that have
nothing to do with this library's getline. They would not be
compilable if all features were enabled indiscriminately.

This should not be used to verify that a program conforms to a limited
standard. It is insufficient for this purpose, as it will not protect you
from including header files outside the standard, or relying on semantics
undefined within the standard.

Macro:_POSIX_SOURCE

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.

The state of _POSIX_SOURCE is irrelevant if you define the
macro _POSIX_C_SOURCE to a positive integer.

Macro:_POSIX_C_SOURCE

Define this macro to a positive integer to control which POSIX
functionality is made available. The greater the value of this macro,
the more functionality is made available.

If you define this macro to a value greater than or equal to 1,
then the functionality from the 1990 edition of the POSIX.1 standard
(IEEE Standard 1003.1-1990) is made available.

If you define this macro to a value greater than or equal to 2,
then the functionality from the 1992 edition of the POSIX.2 standard
(IEEE Standard 1003.2-1992) is made available.

If you define this macro to a value greater than or equal to 199309L,
then the functionality from the 1993 edition of the POSIX.1b standard
(IEEE Standard 1003.1b-1993) is made available.

Greater values for _POSIX_C_SOURCE will enable future extensions.
The POSIX standards process will define these values as necessary, and
the GNU C Library should support them some time after they become standardized.
The 1996 edition of POSIX.1 (ISO/IEC 9945-1: 1996) states that
if you define _POSIX_C_SOURCE to a value greater than
or equal to 199506L, then the functionality from the 1996
edition is made available.

Macro:_BSD_SOURCE

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 BSD 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 _BSD_SOURCE, you must give the option `-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.

Macro:_SVID_SOURCE

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.

Macro:_XOPEN_SOURCE

Macro:_XOPEN_SOURCE_EXTENDED

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 _POSIX_SOURCE and
_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 _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.

If the macro _XOPEN_SOURCE has the value @math{500} this includes
all functionality described so far plus some new definitions from the
Single Unix Specification, version 2.

Macro:_LARGEFILE_SOURCE

If this macro is defined some extra functions are available which
rectify a few shortcomings in all previous standards. Specifically,
the functions fseeko and ftello are available. Without
these functions the difference between the ISO C interface
(fseek, ftell) and the low-level POSIX interface
(lseek) would lead to problems.

This macro was introduced as part of the Large File Support extension (LFS).

Macro:_LARGEFILE64_SOURCE

If you define this macro an additional set of functions is made available
which enables 32 bit systems to use files of sizes beyond
the usual limit of 2GB. This interface is not available if the system
does not support files that large. On systems where the natural file
size limit is greater than 2GB (i.e., on 64 bit systems) the new
functions are identical to the replaced functions.

The new functionality is made available by a new set of types and
functions which replace the existing ones. The names of these new objects
contain 64 to indicate the intention, e.g., off_t
vs. off64_t and fseeko vs. fseeko64.

This macro was introduced as part of the Large File Support extension
(LFS). It is a transition interface for the period when 64 bit
offsets are not generally used (see _FILE_OFFSET_BITS).

Macro:_FILE_OFFSET_BITS

This macro determines which file system interface shall be used, one
replacing the other. Whereas _LARGEFILE64_SOURCE makes the 64
bit interface available as an additional interface,
_FILE_OFFSET_BITS allows the 64 bit interface to
replace the old interface.

If _FILE_OFFSET_BITS is undefined, or if it is defined to the
value 32, nothing changes. The 32 bit interface is used and
types like off_t have a size of 32 bits on 32 bit
systems.

If the macro is defined to the value 64, the large file interface
replaces the old interface. I.e., the functions are not made available
under different names (as they are with _LARGEFILE64_SOURCE).
Instead the old function names now reference the new functions, e.g., a
call to fseeko now indeed calls fseeko64.

This macro should only be selected if the system provides mechanisms for
handling large files. On 64 bit systems this macro has no effect
since the *64 functions are identical to the normal functions.

This macro was introduced as part of the Large File Support extension
(LFS).

Macro:_ISOC99_SOURCE

Until the revised ISO C standard is widely adopted the new features
are not automatically enabled. The GNU libc nevertheless has a complete
implementation of the new standard and to enable the new features the
macro _ISOC99_SOURCE should be defined.

Macro:_GNU_SOURCE

If you define this macro, everything is included: ISO C89, ISO
C99, POSIX.1, POSIX.2, BSD, SVID, X/Open, LFS, 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 _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 `-lbsd-compat' option to the
compiler or linker. Note: If you forget to do this, you may
get very strange errors at run time.

Macro:_REENTRANT

Macro:_THREAD_SAFE

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 the delay in the standardization of the thread safe C library
interface.

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 _GNU_SOURCE in new programs. If you don't
specify the `-ansi' option to GCC and don't define any of these
macros explicitly, the effect is the same as defining
_POSIX_C_SOURCE to 2 and _POSIX_SOURCE,
_SVID_SOURCE, and _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 _POSIX_C_SOURCE, then
defining _POSIX_SOURCE as well has no effect. Likewise, if you
define _GNU_SOURCE, then defining either _POSIX_SOURCE or
_POSIX_C_SOURCE or _SVID_SOURCE as well has no effect.

Note, however, that the features of _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
_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.

Here is an overview of the contents of the remaining chapters of
this manual.

section Error Reporting, describes how errors detected by the library
are reported.

section C Language Facilities in the Library, contains information about library support for
standard parts of the C language, including things like the sizeof
operator and the symbolic constant NULL, 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 Virtual Memory Allocation And Paging, describes the GNU library's facilities for managing and
using virtual and real memory, including dynamic allocation of virtual
memory. If you do not know in advance how much memory your program
needs, you can allocate it dynamically instead, and manipulate it via
pointers.

section Character Handling, contains information about character
classification functions (such as isspace) and functions for
performing case conversion.

section 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 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 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 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 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 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 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 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 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 Pattern Matching, presents functions for matching regular expressions
and shell file name patterns, and for expanding words as the shell does.

section Date and Time, describes functions for measuring both calendar time
and CPU time, as well as functions for setting alarms and timers.

section Character Set Handling, contains information about manipulating
characters and strings using character sets larger than will fit in
the usual char data type.

section 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 Non-Local Exits, contains descriptions of the setjmp and
longjmp functions. These functions provide a facility for
goto-like jumps which can jump from one function to another.

section 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 Processes, contains information about how to start new processes
and run programs.

section 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 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 System Management, describes functions for controlling and getting
information about the hardware and software configuration your program
is executing under.

section 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 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 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 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.