This is Edition 0.10, last updated 2001-07-06, of The GNU C Library Reference Manual, for Version 2.3.x.
Copyright (C) 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2001, 2002, 2003 Free Software Foundation, Inc.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being "Free Software Needs Free Documentation" and "GNU Lesser General Public License", the Front-Cover texts being (a) (see below), and with the Back-Cover Texts being (b) (see below). A copy of the license is included in the section entitled "GNU Free Documentation License".
(a) The FSF's Front-Cover Text is:
A GNU Manual
(b) The FSF's Back-Cover Text is:
You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development.
This is Edition 0.10, last updated 2001-07-06, of The GNU C Library Reference Manual, for Version 2.3.x of the GNU C Library.
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 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 Library Summary, 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 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 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 File System Interface), device-specific terminal control functions (see Low-Level Terminal Interface), and process control functions (see 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 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 BSD facilities include symbolic links (see Symbolic Links), the
select function (see Waiting for I/O), the BSD signal
functions (see BSD Signal Handling), and sockets (see Sockets).
The System 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 POSIX).
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.
This section describes some of the practical issues involved in using the GNU C library.
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 Feature Test Macros).
For more information about the use of header files and #include
directives, see Header Files.
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:
#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.
#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.
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:
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.
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.
E followed a digit or uppercase
letter may be used for additional error code names. See Error Reporting.
is or to followed by a
lowercase letter may be used for additional character testing and
conversion functions. See Character Handling.
LC_ followed by an uppercase letter may be
used for additional macros specifying locale attributes.
See Locales.
f or l are reserved for corresponding
functions that operate on float and long double arguments,
respectively.
SIG followed by an uppercase letter are
reserved for additional signal names. See Standard Signals.
SIG_ followed by an uppercase letter are
reserved for additional signal actions. See Basic Signal Handling.
str, mem, or wcs followed by a
lowercase letter are reserved for additional string and array functions.
See String and Array Utilities.
_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.
dirent.h reserves names prefixed with
d_.
fcntl.h reserves names prefixed with
l_, F_, O_, and S_.
grp.h reserves names prefixed with gr_.
limits.h reserves names suffixed with _MAX.
pwd.h reserves names prefixed with pw_.
signal.h reserves names prefixed with sa_
and SA_.
sys/stat.h reserves names prefixed with st_
and S_.
sys/times.h reserves names prefixed with tms_.
termios.h reserves names prefixed with c_,
V, I, O, and TC; and names prefixed with
B followed by a digit.
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 GNU CC Command Options,
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.
| _POSIX_SOURCE | Macro |
|
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_C_SOURCE | Macro |
|
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 If you define this macro to a value greater than or equal to If you define this macro to a value greater than or equal to Greater values for |
| _BSD_SOURCE | Macro |
|
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 |
| _SVID_SOURCE | Macro |
| 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. |
| _XOPEN_SOURCE | Macro |
| _XOPEN_SOURCE_EXTENDED | Macro |
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 If the macro |
| _LARGEFILE_SOURCE | Macro |
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). |
| _LARGEFILE64_SOURCE | Macro |
| 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 |