   This file documents the GNU C library.

   This is Edition 0.10, last updated 2001-07-06, of `The GNU C Library
Reference Manual', for Version 2.2.x.

   Copyright (C) 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2001, 2002
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.

Error Codes
===========

   The error code macros are defined in the header file `errno.h'.  All
of them expand into integer constant values.  Some of these error codes
can't occur on the GNU system, but they can occur using the GNU library
on other systems.

 - Macro: int EPERM
     Operation not permitted; only the owner of the file (or other
     resource) or processes with special privileges can perform the
     operation.

 - Macro: int ENOENT
     No such file or directory.  This is a "file doesn't exist" error
     for ordinary files that are referenced in contexts where they are
     expected to already exist.

 - Macro: int ESRCH
     No process matches the specified process ID.

 - Macro: int EINTR
     Interrupted function call; an asynchronous signal occurred and
     prevented completion of the call.  When this happens, you should
     try the call again.

     You can choose to have functions resume after a signal that is
     handled, rather than failing with `EINTR'; see Interrupted Primitives.

 - Macro: int EIO
     Input/output error; usually used for physical read or write errors.

 - Macro: int ENXIO
     No such device or address.  The system tried to use the device
     represented by a file you specified, and it couldn't find the
     device.  This can mean that the device file was installed
     incorrectly, or that the physical device is missing or not
     correctly attached to the computer.

 - Macro: int E2BIG
     Argument list too long; used when the arguments passed to a new
     program being executed with one of the `exec' functions (see
     Executing a File) occupy too much memory space.  This condition
     never arises in the GNU system.

 - Macro: int ENOEXEC
     Invalid executable file format.  This condition is detected by the
     `exec' functions; see Executing a File.

 - Macro: int EBADF
     Bad file descriptor; for example, I/O on a descriptor that has been
     closed or reading from a descriptor open only for writing (or vice
     versa).

 - Macro: int ECHILD
     There are no child processes.  This error happens on operations
     that are supposed to manipulate child processes, when there aren't
     any processes to manipulate.

 - Macro: int EDEADLK
     Deadlock avoided; allocating a system resource would have resulted
     in a deadlock situation.  The system does not guarantee that it
     will notice all such situations.  This error means you got lucky
     and the system noticed; it might just hang.  See File Locks,
     for an example.

 - Macro: int ENOMEM
     No memory available.  The system cannot allocate more virtual
     memory because its capacity is full.

 - Macro: int EACCES
     Permission denied; the file permissions do not allow the attempted
     operation.

 - Macro: int EFAULT
     Bad address; an invalid pointer was detected.  In the GNU system,
     this error never happens; you get a signal instead.

 - Macro: int ENOTBLK
     A file that isn't a block special file was given in a situation
     that requires one.  For example, trying to mount an ordinary file
     as a file system in Unix gives this error.

 - Macro: int EBUSY
     Resource busy; a system resource that can't be shared is already
     in use.  For example, if you try to delete a file that is the root
     of a currently mounted filesystem, you get this error.

 - Macro: int EEXIST
     File exists; an existing file was specified in a context where it
     only makes sense to specify a new file.

 - Macro: int EXDEV
     An attempt to make an improper link across file systems was
     detected.  This happens not only when you use `link' (see Hard Links)
     but also when you rename a file with `rename' (see
     Renaming Files).

 - Macro: int ENODEV
     The wrong type of device was given to a function that expects a
     particular sort of device.

 - Macro: int ENOTDIR
     A file that isn't a directory was specified when a directory is
     required.

 - Macro: int EISDIR
     File is a directory; you cannot open a directory for writing, or
     create or remove hard links to it.

 - Macro: int EINVAL
     Invalid argument.  This is used to indicate various kinds of
     problems with passing the wrong argument to a library function.

 - Macro: int EMFILE
     The current process has too many files open and can't open any
     more.  Duplicate descriptors do count toward this limit.

     In BSD and GNU, the number of open files is controlled by a
     resource limit that can usually be increased.  If you get this
     error, you might want to increase the `RLIMIT_NOFILE' limit or
     make it unlimited; see Limits on Resources.

 - Macro: int ENFILE
     There are too many distinct file openings in the entire system.
     Note that any number of linked channels count as just one file
     opening; see Linked Channels.  This error never occurs in
     the GNU system.

 - Macro: int ENOTTY
     Inappropriate I/O control operation, such as trying to set terminal
     modes on an ordinary file.

 - Macro: int ETXTBSY
     An attempt to execute a file that is currently open for writing, or
     write to a file that is currently being executed.  Often using a
     debugger to run a program is considered having it open for writing
     and will cause this error.  (The name stands for "text file
     busy".)  This is not an error in the GNU system; the text is
     copied as necessary.

 - Macro: int EFBIG
     File too big; the size of a file would be larger than allowed by
     the system.

 - Macro: int ENOSPC
     No space left on device; write operation on a file failed because
     the disk is full.

 - Macro: int ESPIPE
     Invalid seek operation (such as on a pipe).

 - Macro: int EROFS
     An attempt was made to modify something on a read-only file system.

 - Macro: int EMLINK
     Too many links; the link count of a single file would become too
     large.  `rename' can cause this error if the file being renamed
     already has as many links as it can take (see Renaming Files).

 - Macro: int EPIPE
     Broken pipe; there is no process reading from the other end of a
     pipe.  Every library function that returns this error code also
     generates a `SIGPIPE' signal; this signal terminates the program
     if not handled or blocked.  Thus, your program will never actually
     see `EPIPE' unless it has handled or blocked `SIGPIPE'.

 - Macro: int EDOM
     Domain error; used by mathematical functions when an argument
     value does not fall into the domain over which the function is
     defined.

 - Macro: int ERANGE
     Range error; used by mathematical functions when the result value
     is not representable because of overflow or underflow.

 - Macro: int EAGAIN
     Resource temporarily unavailable; the call might work if you try
     again later.  The macro `EWOULDBLOCK' is another name for `EAGAIN';
     they are always the same in the GNU C library.

     This error can happen in a few different situations:

        * An operation that would block was attempted on an object that
          has non-blocking mode selected.  Trying the same operation
          again will block until some external condition makes it
          possible to read, write, or connect (whatever the operation).
          You can use `select' to find out when the operation will be
          possible; see Waiting for I/O.

          *Portability Note:* In many older Unix systems, this condition
          was indicated by `EWOULDBLOCK', which was a distinct error
          code different from `EAGAIN'.  To make your program portable,
          you should check for both codes and treat them the same.

        * A temporary resource shortage made an operation impossible.
          `fork' can return this error.  It indicates that the shortage
          is expected to pass, so your program can try the call again
          later and it may succeed.  It is probably a good idea to
          delay for a few seconds before trying it again, to allow time
          for other processes to release scarce resources.  Such
          shortages are usually fairly serious and affect the whole
          system, so usually an interactive program should report the
          error to the user and return to its command loop.

 - Macro: int EWOULDBLOCK
     In the GNU C library, this is another name for `EAGAIN' (above).
     The values are always the same, on every operating system.

     C libraries in many older Unix systems have `EWOULDBLOCK' as a
     separate error code.

 - Macro: int EINPROGRESS
     An operation that cannot complete immediately was initiated on an
     object that has non-blocking mode selected.  Some functions that
     must always block (such as `connect'; see Connecting) never
     return `EAGAIN'.  Instead, they return `EINPROGRESS' to indicate
     that the operation has begun and will take some time.  Attempts to
     manipulate the object before the call completes return `EALREADY'.
     You can use the `select' function to find out when the pending
     operation has completed; see Waiting for I/O.

 - Macro: int EALREADY
     An operation is already in progress on an object that has
     non-blocking mode selected.

 - Macro: int ENOTSOCK
     A file that isn't a socket was specified when a socket is required.

 - Macro: int EMSGSIZE
     The size of a message sent on a socket was larger than the
     supported maximum size.

 - Macro: int EPROTOTYPE
     The socket type does not support the requested communications
     protocol.

 - Macro: int ENOPROTOOPT
     You specified a socket option that doesn't make sense for the
     particular protocol being used by the socket.  See Socket Options.

 - Macro: int EPROTONOSUPPORT
     The socket domain does not support the requested communications
     protocol (perhaps because the requested protocol is completely
     invalid).  See Creating a Socket.

 - Macro: int ESOCKTNOSUPPORT
     The socket type is not supported.

 - Macro: int EOPNOTSUPP
     The operation you requested is not supported.  Some socket
     functions don't make sense for all types of sockets, and others
     may not be implemented for all communications protocols.  In the
     GNU system, this error can happen for many calls when the object
     does not support the particular operation; it is a generic
     indication that the server knows nothing to do for that call.

 - Macro: int EPFNOSUPPORT
     The socket communications protocol family you requested is not
     supported.

 - Macro: int EAFNOSUPPORT
     The address family specified for a socket is not supported; it is
     inconsistent with the protocol being used on the socket.  See
     Sockets.

 - Macro: int EADDRINUSE
     The requested socket address is already in use.  See Socket Addresses.

 - Macro: int EADDRNOTAVAIL
     The requested socket address is not available; for example, you
     tried to give a socket a name that doesn't match the local host
     name.  See Socket Addresses.

 - Macro: int ENETDOWN
     A socket operation failed because the network was down.

 - Macro: int ENETUNREACH
     A socket operation failed because the subnet containing the remote
     host was unreachable.

 - Macro: int ENETRESET
     A network connection was reset because the remote host crashed.

 - Macro: int ECONNABORTED
     A network connection was aborted locally.

 - Macro: int ECONNRESET
     A network connection was closed for reasons outside the control of
     the local host, such as by the remote machine rebooting or an
     unrecoverable protocol violation.

 - Macro: int ENOBUFS
     The kernel's buffers for I/O operations are all in use.  In GNU,
     this error is always synonymous with `ENOMEM'; you may get one or
     the other from network operations.

 - Macro: int EISCONN
     You tried to connect a socket that is already connected.  See
     Connecting.

 - Macro: int ENOTCONN
     The socket is not connected to anything.  You get this error when
     you try to transmit data over a socket, without first specifying a
     destination for the data.  For a connectionless socket (for
     datagram protocols, such as UDP), you get `EDESTADDRREQ' instead.

 - Macro: int EDESTADDRREQ
     No default destination address was set for the socket.  You get
     this error when you try to transmit data over a connectionless
     socket, without first specifying a destination for the data with
     `connect'.

 - Macro: int ESHUTDOWN
     The socket has already been shut down.

 - Macro: int ETOOMANYREFS
     ???

 - Macro: int ETIMEDOUT
     A socket operation with a specified timeout received no response
     during the timeout period.

 - Macro: int ECONNREFUSED
     A remote host refused to allow the network connection (typically
     because it is not running the requested service).

 - Macro: int ELOOP
     Too many levels of symbolic links were encountered in looking up a
     file name.  This often indicates a cycle of symbolic links.

 - Macro: int ENAMETOOLONG
     Filename too long (longer than `PATH_MAX'; see Limits for Files)
     or host name too long (in `gethostname' or `sethostname';
     see Host Identification).

 - Macro: int EHOSTDOWN
     The remote host for a requested network connection is down.

 - Macro: int EHOSTUNREACH
     The remote host for a requested network connection is not
     reachable.

 - Macro: int ENOTEMPTY
     Directory not empty, where an empty directory was expected.
     Typically, this error occurs when you are trying to delete a
     directory.

 - Macro: int EPROCLIM
     This means that the per-user limit on new process would be
     exceeded by an attempted `fork'.  See Limits on Resources, for
     details on the `RLIMIT_NPROC' limit.

 - Macro: int EUSERS
     The file quota system is confused because there are too many users.

 - Macro: int EDQUOT
     The user's disk quota was exceeded.

 - Macro: int ESTALE
     Stale NFS file handle.  This indicates an internal confusion in
     the NFS system which is due to file system rearrangements on the
     server host.  Repairing this condition usually requires unmounting
     and remounting the NFS file system on the local host.

 - Macro: int EREMOTE
     An attempt was made to NFS-mount a remote file system with a file
     name that already specifies an NFS-mounted file.  (This is an
     error on some operating systems, but we expect it to work properly
     on the GNU system, making this error code impossible.)

 - Macro: int EBADRPC
     ???

 - Macro: int ERPCMISMATCH
     ???

 - Macro: int EPROGUNAVAIL
     ???

 - Macro: int EPROGMISMATCH
     ???

 - Macro: int EPROCUNAVAIL
     ???

 - Macro: int ENOLCK
     No locks available.  This is used by the file locking facilities;
     see File Locks.  This error is never generated by the GNU
     system, but it can result from an operation to an NFS server
     running another operating system.

 - Macro: int EFTYPE
     Inappropriate file type or format.  The file was the wrong type
     for the operation, or a data file had the wrong format.

     On some systems `chmod' returns this error if you try to set the
     sticky bit on a non-directory file; see Setting Permissions.

 - Macro: int EAUTH
     ???

 - Macro: int ENEEDAUTH
     ???

 - Macro: int ENOSYS
     Function not implemented.  This indicates that the function called
     is not implemented at all, either in the C library itself or in the
     operating system.  When you get this error, you can be sure that
     this particular function will always fail with `ENOSYS' unless you
     install a new version of the C library or the operating system.

 - Macro: int ENOTSUP
     Not supported.  A function returns this error when certain
     parameter values are valid, but the functionality they request is
     not available.  This can mean that the function does not implement
     a particular command or option value or flag bit at all.  For
     functions that operate on some object given in a parameter, such
     as a file descriptor or a port, it might instead mean that only
     _that specific object_ (file descriptor, port, etc.) is unable to
     support the other parameters given; different file descriptors
     might support different ranges of parameter values.

     If the entire function is not available at all in the
     implementation, it returns `ENOSYS' instead.

 - Macro: int EILSEQ
     While decoding a multibyte character the function came along an
     invalid or an incomplete sequence of bytes or the given wide
     character is invalid.

 - Macro: int EBACKGROUND
     In the GNU system, servers supporting the `term' protocol return
     this error for certain operations when the caller is not in the
     foreground process group of the terminal.  Users do not usually
     see this error because functions such as `read' and `write'
     translate it into a `SIGTTIN' or `SIGTTOU' signal.  See Job Control,
     for information on process groups and these signals.

 - Macro: int EDIED
     In the GNU system, opening a file returns this error when the file
     is translated by a program and the translator program dies while
     starting up, before it has connected to the file.

 - Macro: int ED
     The experienced user will know what is wrong.

 - Macro: int EGREGIOUS
     You did *what*?

 - Macro: int EIEIO
     Go home and have a glass of warm, dairy-fresh milk.

 - Macro: int EGRATUITOUS
     This error code has no purpose.

 - Macro: int EBADMSG

 - Macro: int EIDRM

 - Macro: int EMULTIHOP

 - Macro: int ENODATA

 - Macro: int ENOLINK

 - Macro: int ENOMSG

 - Macro: int ENOSR

 - Macro: int ENOSTR

 - Macro: int EOVERFLOW

 - Macro: int EPROTO

 - Macro: int ETIME

   _The following error codes are defined by the Linux/i386 kernel.
They are not yet documented._

 - Macro: int ERESTART

 - Macro: int ECHRNG

 - Macro: int EL2NSYNC

 - Macro: int EL3HLT

 - Macro: int EL3RST

 - Macro: int ELNRNG

 - Macro: int EUNATCH

 - Macro: int ENOCSI

 - Macro: int EL2HLT

 - Macro: int EBADE

 - Macro: int EBADR

 - Macro: int EXFULL

 - Macro: int ENOANO

 - Macro: int EBADRQC

 - Macro: int EBADSLT

 - Macro: int EDEADLOCK

 - Macro: int EBFONT

 - Macro: int ENONET

 - Macro: int ENOPKG

 - Macro: int EADV

 - Macro: int ESRMNT

 - Macro: int ECOMM

 - Macro: int EDOTDOT

 - Macro: int ENOTUNIQ

 - Macro: int EBADFD

 - Macro: int EREMCHG

 - Macro: int ELIBACC

 - Macro: int ELIBBAD

 - Macro: int ELIBSCN

 - Macro: int ELIBMAX

 - Macro: int ELIBEXEC

 - Macro: int ESTRPIPE

 - Macro: int EUCLEAN

 - Macro: int ENOTNAM

 - Macro: int ENAVAIL

 - Macro: int EISNAM

 - Macro: int EREMOTEIO

 - Macro: int ENOMEDIUM

 - Macro: int EMEDIUMTYPE

Error Messages
==============

   The library has functions and variables designed to make it easy for
your program to report informative error messages in the customary
format about the failure of a library call.  The functions `strerror'
and `perror' give you the standard error message for a given error
code; the variable `program_invocation_short_name' gives you convenient
access to the name of the program that encountered the error.

 - Function: char * strerror (int ERRNUM)
     The `strerror' function maps the error code (see Checking for Errors)
     specified by the ERRNUM argument to a descriptive error
     message string.  The return value is a pointer to this string.

     The value ERRNUM normally comes from the variable `errno'.

     You should not modify the string returned by `strerror'.  Also, if
     you make subsequent calls to `strerror', the string might be
     overwritten.  (But it's guaranteed that no library function ever
     calls `strerror' behind your back.)

     The function `strerror' is declared in `string.h'.

 - Function: char * strerror_r (int ERRNUM, char *BUF, size_t N)
     The `strerror_r' function works like `strerror' but instead of
     returning the error message in a statically allocated buffer
     shared by all threads in the process, it returns a private copy
     for the thread. This might be either some permanent global data or
     a message string in the user supplied buffer starting at BUF with
     the length of N bytes.

     At most N characters are written (including the NUL byte) so it is
     up to the user to select the buffer large enough.

     This function should always be used in multi-threaded programs
     since there is no way to guarantee the string returned by
     `strerror' really belongs to the last call of the current thread.

     This function `strerror_r' is a GNU extension and it is declared in
     `string.h'.

 - Function: void perror (const char *MESSAGE)
     This function prints an error message to the stream `stderr'; see
     Standard Streams.  The orientation of `stderr' is not
     changed.

     If you call `perror' with a MESSAGE that is either a null pointer
     or an empty string, `perror' just prints the error message
     corresponding to `errno', adding a trailing newline.

     If you supply a non-null MESSAGE argument, then `perror' prefixes
     its output with this string.  It adds a colon and a space
     character to separate the MESSAGE from the error string
     corresponding to `errno'.

     The function `perror' is declared in `stdio.h'.

   `strerror' and `perror' produce the exact same message for any given
error code; the precise text varies from system to system.  On the GNU
system, the messages are fairly short; there are no multi-line messages
or embedded newlines.  Each error message begins with a capital letter
and does not include any terminating punctuation.

   *Compatibility Note:* The `strerror' function was introduced in
ISO C89.  Many older C systems do not support this function yet.

   Many programs that don't read input from the terminal are designed to
exit if any system call fails.  By convention, the error message from
such a program should start with the program's name, sans directories.
You can find that name in the variable `program_invocation_short_name';
the full file name is stored the variable `program_invocation_name'.

 - Variable: char * program_invocation_name
     This variable's value is the name that was used to invoke the
     program running in the current process.  It is the same as
     `argv[0]'.  Note that this is not necessarily a useful file name;
     often it contains no directory names.  See Program Arguments.

 - Variable: char * program_invocation_short_name
     This variable's value is the name that was used to invoke the
     program running in the current process, with directory names
     removed.  (That is to say, it is the same as
     `program_invocation_name' minus everything up to the last slash,
     if any.)

   The library initialization code sets up both of these variables
before calling `main'.

   *Portability Note:* These two variables are GNU extensions.  If you
want your program to work with non-GNU libraries, you must save the
value of `argv[0]' in `main', and then strip off the directory names
yourself.  We added these extensions to make it possible to write
self-contained error-reporting subroutines that require no explicit
cooperation from `main'.

   Here is an example showing how to handle failure to open a file
correctly.  The function `open_sesame' tries to open the named file for
reading and returns a stream if successful.  The `fopen' library
function returns a null pointer if it couldn't open the file for some
reason.  In that situation, `open_sesame' constructs an appropriate
error message using the `strerror' function, and terminates the
program.  If we were going to make some other library calls before
passing the error code to `strerror', we'd have to save it in a local
variable instead, because those other library functions might overwrite
`errno' in the meantime.

     #include <errno.h>
     #include <stdio.h>
     #include <stdlib.h>
     #include <string.h>

     FILE *
     open_sesame (char *name)
     {
       FILE *stream;

       errno = 0;
       stream = fopen (name, "r");
       if (stream == NULL)
         {
           fprintf (stderr, "%s: Couldn't open file %s; %s\n",
                    program_invocation_short_name, name, strerror (errno));
           exit (EXIT_FAILURE);
         }
       else
         return stream;
     }

   Using `perror' has the advantage that the function is portable and
available on all systems implementing ISO C.  But often the text
`perror' generates is not what is wanted and there is no way to extend
or change what `perror' does.  The GNU coding standard, for instance,
requires error messages to be preceded by the program name and programs
which read some input files should should provide information about the
input file name and the line number in case an error is encountered
while reading the file.  For these occasions there are two functions
available which are widely used throughout the GNU project.  These
functions are declared in `error.h'.

 - Function: void error (int STATUS, int ERRNUM, const char *FORMAT,
          ...)
     The `error' function can be used to report general problems during
     program execution.  The FORMAT argument is a format string just
     like those given to the `printf' family of functions.  The
     arguments required for the format can follow the FORMAT parameter.
     Just like `perror', `error' also can report an error code in
     textual form.  But unlike `perror' the error value is explicitly
     passed to the function in the ERRNUM parameter.  This elimintates
     the problem mentioned above that the error reporting function must
     be called immediately after the function causing the error since
     otherwise `errno' might have a different value.

     The `error' prints first the program name.  If the application
     defined a global variable `error_print_progname' and points it to a
     function this function will be called to print the program name.
     Otherwise the string from the global variable `program_name' is
     used.  The program name is followed by a colon and a space which
     in turn is followed by the output produced by the format string.
     If the ERRNUM parameter is non-zero the format string output is
     followed by a colon and a space, followed by the error message for
     the error code ERRNUM.  In any case is the output terminated with
     a newline.

     The output is directed to the `stderr' stream.  If the `stderr'
     wasn't oriented before the call it will be narrow-oriented
     afterwards.

     The function will return unless the STATUS parameter has a
     non-zero value.  In this case the function will call `exit' with
     the STATUS value for its parameter and therefore never return.  If
     `error' returns the global variable `error_message_count' is
     incremented by one to keep track of the number of errors reported.

 - Function: void error_at_line (int STATUS, int ERRNUM, const char
          *FNAME, unsigned int LINENO, const char *FORMAT, ...)
     The `error_at_line' function is very similar to the `error'
     function.  The only difference are the additional parameters FNAME
     and LINENO.  The handling of the other parameters is identical to
     that of `error' except that between the program name and the string
     generated by the format string additional text is inserted.

     Directly following the program name a colon, followed by the file
     name pointer to by FNAME, another colon, and a value of LINENO is
     printed.

     This additional output of course is meant to be used to locate an
     error in an input file (like a programming language source code
     file etc).

     If the global variable `error_one_per_line' is set to a non-zero
     value `error_at_line' will avoid printing consecutive messages for
     the same file anem line.  Repetition which are not directly
     following each other are not caught.

     Just like `error' this function only returned if STATUS is zero.
     Otherwise `exit' is called with the non-zero value.  If `error'
     returns the global variable `error_message_count' is incremented
     by one to keep track of the number of errors reported.

   As mentioned above the `error' and `error_at_line' functions can be
customized by defining a variable named `error_print_progname'.

 - Variable: void (* error_print_progname ) (void)
     If the `error_print_progname' variable is defined to a non-zero
     value the function pointed to is called by `error' or
     `error_at_line'.  It is expected to print the program name or do
     something similarly useful.

     The function is expected to be print to the `stderr' stream and
     must be able to handle whatever orientation the stream has.

     The variable is global and shared by all threads.

 - Variable: unsigned int error_message_count
     The `error_message_count' variable is incremented whenever one of
     the functions `error' or `error_at_line' returns.  The variable is
     global and shared by all threads.

 - Variable: int error_one_per_line
     The `error_one_per_line' variable influences only `error_at_line'.
     Normally the `error_at_line' function creates output for every
     invocation.  If `error_one_per_line' is set to a non-zero value
     `error_at_line' keeps track of the last file name and line number
     for which an error was reported and avoid directly following
     messages for the same file and line.  This variable is global and
     shared by all threads.

A program which read some input file and reports errors in it could look
like this:

     {
       char *line = NULL;
       size_t len = 0;
       unsigned int lineno = 0;

       error_message_count = 0;
       while (! feof_unlocked (fp))
         {
           ssize_t n = getline (&line, &len, fp);
           if (n <= 0)
             /* End of file or error.  */
             break;
           ++lineno;

           /* Process the line.  */
           ...

           if (Detect error in line)
             error_at_line (0, errval, filename, lineno,
                            "some error text %s", some_variable);
         }

       if (error_message_count != 0)
         error (EXIT_FAILURE, 0, "%u errors found", error_message_count);
     }

   `error' and `error_at_line' are clearly the functions of choice and
enable the programmer to write applications which follow the GNU coding
standard.  The GNU libc additionally contains functions which are used
in BSD for the same purpose.  These functions are declared in `err.h'.
It is generally advised to not use these functions.  They are included
only for compatibility.

 - Function: void warn (const char *FORMAT, ...)
     The `warn' function is roughly equivalent to a call like
            error (0, errno, format, the parameters)

     except that the global variables `error' respects and modifies are
     not used.

 - Function: void vwarn (const char *FORMAT, va_list)
     The `vwarn' function is just like `warn' except that the
     parameters for the handling of the format string FORMAT are passed
     in as an value of type `va_list'.

 - Function: void warnx (const char *FORMAT, ...)
     The `warnx' function is roughly equivalent to a call like
            error (0, 0, format, the parameters)

     except that the global variables `error' respects and modifies are
     not used.  The difference to `warn' is that no error number string
     is printed.

 - Function: void vwarnx (const char *FORMAT, va_list)
     The `vwarnx' function is just like `warnx' except that the
     parameters for the handling of the format string FORMAT are passed
     in as an value of type `va_list'.

 - Function: void err (int STATUS, const char *FORMAT, ...)
     The `err' function is roughly equivalent to a call like
            error (status, errno, format, the parameters)

     except that the global variables `error' respects and modifies are
     not used and that the program is exited even if STATUS is zero.

 - Function: void verr (int STATUS, const char *FORMAT, va_list)
     The `verr' function is just like `err' except that the parameters
     for the handling of the format string FORMAT are passed in as an
     value of type `va_list'.

 - Function: void errx (int STATUS, const char *FORMAT, ...)
     The `errx' function is roughly equivalent to a call like
            error (status, 0, format, the parameters)

     except that the global variables `error' respects and modifies are
     not used and that the program is exited even if STATUS is zero.
     The difference to `err' is that no error number string is printed.

 - Function: void verrx (int STATUS, const char *FORMAT, va_list)
     The `verrx' function is just like `errx' except that the
     parameters for the handling of the format string FORMAT are passed
     in as an value of type `va_list'.

Virtual Memory Allocation And Paging
************************************

   This chapter describes how processes manage and use memory in a
system that uses the GNU C library.

   The GNU C Library has several functions for dynamically allocating
virtual memory in various ways.  They vary in generality and in
efficiency.  The library also provides functions for controlling paging
and allocation of real memory.

   Memory mapped I/O is not discussed in this chapter.  See
Memory-mapped I/O.

Process Memory Concepts
=======================

   One of the most basic resources a process has available to it is
memory.  There are a lot of different ways systems organize memory, but
in a typical one, each process has one linear virtual address space,
with addresses running from zero to some huge maximum.  It need not be
contiguous; i.e.  not all of these addresses actually can be used to
store data.

   The virtual memory is divided into pages (4 kilobytes is typical).
Backing each page of virtual memory is a page of real memory (called a
"frame") or some secondary storage, usually disk space.  The disk space
might be swap space or just some ordinary disk file.  Actually, a page
of all zeroes sometimes has nothing at all backing it - there's just a
flag saying it is all zeroes.

   The same frame of real memory or backing store can back multiple
virtual pages belonging to multiple processes.  This is normally the
case, for example, with virtual memory occupied by GNU C library code.
The same real memory frame containing the `printf' function backs a
virtual memory page in each of the existing processes that has a
`printf' call in its program.

   In order for a program to access any part of a virtual page, the page
must at that moment be backed by ("connected to") a real frame.  But
because there is usually a lot more virtual memory than real memory, the
pages must move back and forth between real memory and backing store
regularly, coming into real memory when a process needs to access them
and then retreating to backing store when not needed anymore.  This
movement is called "paging".

   When a program attempts to access a page which is not at that moment
backed by real memory, this is known as a "page fault".  When a page
fault occurs, the kernel suspends the process, places the page into a
real page frame (this is called "paging in" or "faulting in"), then
resumes the process so that from the process' point of view, the page
was in real memory all along.  In fact, to the process, all pages always
seem to be in real memory.  Except for one thing: the elapsed execution
time of an instruction that would normally be a few nanoseconds is
suddenly much, much, longer (because the kernel normally has to do I/O
to complete the page-in).  For programs sensitive to that, the functions
described in Locking Pages can control it.

   Within each virtual address space, a process has to keep track of
what is at which addresses, and that process is called memory
allocation.  Allocation usually brings to mind meting out scarce
resources, but in the case of virtual memory, that's not a major goal,
because there is generally much more of it than anyone needs.  Memory
allocation within a process is mainly just a matter of making sure that
the same byte of memory isn't used to store two different things.

   Processes allocate memory in two major ways: by exec and
programmatically.  Actually, forking is a third way, but it's not very
interesting.  See Creating a Process.

   Exec is the operation of creating a virtual address space for a
process, loading its basic program into it, and executing the program.
It is done by the "exec" family of functions (e.g. `execl').  The
operation takes a program file (an executable), it allocates space to
load all the data in the executable, loads it, and transfers control to
it.  That data is most notably the instructions of the program (the
"text"), but also literals and constants in the program and even some
variables: C variables with the static storage class (see Memory Allocation and C).

   Once that program begins to execute, it uses programmatic allocation
to gain additional memory.  In a C program with the GNU C library, there
are two kinds of programmatic allocation: automatic and dynamic.  See
Memory Allocation and C.

   Memory-mapped I/O is another form of dynamic virtual memory
allocation.  Mapping memory to a file means declaring that the contents
of certain range of a process' addresses shall be identical to the
contents of a specified regular file.  The system makes the virtual
memory initially contain the contents of the file, and if you modify
the memory, the system writes the same modification to the file.  Note
that due to the magic of virtual memory and page faults, there is no
reason for the system to do I/O to read the file, or allocate real
memory for its contents, until the program accesses the virtual memory.
See Memory-mapped I/O.

   Just as it programmatically allocates memory, the program can
programmatically deallocate ("free") it.  You can't free the memory
that was allocated by exec.  When the program exits or execs, you might
say that all its memory gets freed, but since in both cases the address
space ceases to exist, the point is really moot.  See Program Termination.

   A process' virtual address space is divided into segments.  A
segment is a contiguous range of virtual addresses.  Three important
segments are:

   *  The "text segment" contains a program's instructions and literals
     and static constants.  It is allocated by exec and stays the same
     size for the life of the virtual address space.

   * The "data segment" is working storage for the program.  It can be
     preallocated and preloaded by exec and the process can extend or
     shrink it by calling functions as described in Resizing the Data Segment.
     Its lower end is fixed.

   * The "stack segment" contains a program stack.  It grows as the
     stack grows, but doesn't shrink when the stack shrinks.

Allocating Storage For Program Data
===================================

   This section covers how ordinary programs manage storage for their
data, including the famous `malloc' function and some fancier facilities
special the GNU C library and GNU Compiler.

Memory Allocation in C Programs
-------------------------------

   The C language supports two kinds of memory allocation through the
variables in C programs:

   * "Static allocation" is what happens when you declare a static or
     global variable.  Each static or global variable defines one block
     of space, of a fixed size.  The space is allocated once, when your
     program is started (part of the exec operation), and is never
     freed.

   * "Automatic allocation" happens when you declare an automatic
     variable, such as a function argument or a local variable.  The
     space for an automatic variable is allocated when the compound
     statement containing the declaration is entered, and is freed when
     that compound statement is exited.

     In GNU C, the size of the automatic storage can be an expression
     that varies.  In other C implementations, it must be a constant.

   A third important kind of memory allocation, "dynamic allocation",
is not supported by C variables but is available via GNU C library
functions.

Dynamic Memory Allocation
.........................

   "Dynamic memory allocation" is a technique in which programs
determine as they are running where to store some information.  You need
dynamic allocation when the amount of memory you need, or how long you
continue to need it, depends on factors that are not known before the
program runs.

   For example, you may need a block to store a line read from an input
file; since there is no limit to how long a line can be, you must
allocate the memory dynamically and make it dynamically larger as you
read more of the line.

   Or, you may need a block for each record or each definition in the
input data; since you can't know in advance how many there will be, you
must allocate a new block for each record or definition as you read it.

   When you use dynamic allocation, the allocation of a block of memory
is an action that the program requests explicitly.  You call a function
or macro when you want to allocate space, and specify the size with an
argument.  If you want to free the space, you do so by calling another
function or macro.  You can do these things whenever you want, as often
as you want.

   Dynamic allocation is not supported by C variables; there is no
storage class "dynamic", and there can never be a C variable whose
value is stored in dynamically allocated space.  The only way to get
dynamically allocated memory is via a system call (which is generally
via a GNU C library function call), and the only way to refer to
dynamically allocated space is through a pointer.  Because it is less
convenient, and because the actual process of dynamic allocation
requires more computation time, programmers generally use dynamic
allocation only when neither static nor automatic allocation will serve.

   For example, if you want to allocate dynamically some space to hold a
`struct foobar', you cannot declare a variable of type `struct foobar'
whose contents are the dynamically allocated space.  But you can
declare a variable of pointer type `struct foobar *' and assign it the
address of the space.  Then you can use the operators `*' and `->' on
this pointer variable to refer to the contents of the space:

     {
       struct foobar *ptr
          = (struct foobar *) malloc (sizeof (struct foobar));
       ptr->name = x;
       ptr->next = current_foobar;
       current_foobar = ptr;
     }

Unconstrained Allocation
------------------------

   The most general dynamic allocation facility is `malloc'.  It allows
you to allocate blocks of memory of any size at any time, make them
bigger or smaller at any time, and free the blocks individually at any
time (or never).

Basic Memory Allocation
.......................

   To allocate a block of memory, call `malloc'.  The prototype for
this function is in `stdlib.h'.

 - Function: void * malloc (size_t SIZE)
     This function returns a pointer to a newly allocated block SIZE
     bytes long, or a null pointer if the block could not be allocated.

   The contents of the block are undefined; you must initialize it
yourself (or use `calloc' instead; see Allocating Cleared Space).
Normally you would cast the value as a pointer to the kind of object
that you want to store in the block.  Here we show an example of doing
so, and of initializing the space with zeros using the library function
`memset' (see Copying and Concatenation):

     struct foo *ptr;
     ...
     ptr = (struct foo *) malloc (sizeof (struct foo));
     if (ptr == 0) abort ();
     memset (ptr, 0, sizeof (struct foo));

   You can store the result of `malloc' into any pointer variable
without a cast, because ISO C automatically converts the type `void *'
to another type of pointer when necessary.  But the cast is necessary
in contexts other than assignment operators or if you might want your
code to run in traditional C.

   Remember that when allocating space for a string, the argument to
`malloc' must be one plus the length of the string.  This is because a
string is terminated with a null character that doesn't count in the
"length" of the string but does need space.  For example:

     char *ptr;
     ...
     ptr = (char *) malloc (length + 1);

See Representation of Strings, for more information about this.

Examples of `malloc'
....................

   If no more space is available, `malloc' returns a null pointer.  You
should check the value of _every_ call to `malloc'.  It is useful to
write a subroutine that calls `malloc' and reports an error if the
value is a null pointer, returning only if the value is nonzero.  This
function is conventionally called `xmalloc'.  Here it is:

     void *
     xmalloc (size_t size)
     {
       register void *value = malloc (size);
       if (value == 0)
         fatal ("virtual memory exhausted");
       return value;
     }

   Here is a real example of using `malloc' (by way of `xmalloc').  The
function `savestring' will copy a sequence of characters into a newly
allocated null-terminated string:

     char *
     savestring (const char *ptr, size_t len)
     {
       register char *value = (char *) xmalloc (len + 1);
       value[len] = '\0';
       return (char *) memcpy (value, ptr, len);
     }

   The block that `malloc' gives you is guaranteed to be aligned so
that it can hold any type of data.  In the GNU system, the address is
always a multiple of eight on most systems, and a multiple of 16 on
64-bit systems.  Only rarely is any higher boundary (such as a page
boundary) necessary; for those cases, use `memalign', `posix_memalign'
or `valloc' (see Aligned Memory Blocks).

   Note that the memory located after the end of the block is likely to
be in use for something else; perhaps a block already allocated by
another call to `malloc'.  If you attempt to treat the block as longer
than you asked for it to be, you are liable to destroy the data that
`malloc' uses to keep track of its blocks, or you may destroy the
contents of another block.  If you have already allocated a block and
discover you want it to be bigger, use `realloc' (see Changing Block Size).