Dies ist die Info-Datei libc.info, hergestellt von Makeinfo Version
1.68 aus der Eingabe-Datei libc.texinfo.

INFO-DIR-SECTION GNU libraries
START-INFO-DIR-ENTRY
* Libc: (libc).                 C library.
END-INFO-DIR-ENTRY

   This file documents the GNU C library.

   This is Edition 0.07 DRAFT, last updated 4 Oct 1996, of `The GNU C
Library Reference Manual', for Version 2.00 Beta.

   Copyright (C) 1993, '94, '95, '96, '97 Free Software Foundation, Inc.

   Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.

   Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the section entitled "GNU Library General Public License" is
included exactly as in the original, and provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.

   Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the text of the translation of the section
entitled "GNU Library General Public License" must be approved for
accuracy by the Foundation.


File: libc.info,  Node: Version Supported,  Next: Sysconf,  Prev: System Options,  Up: System Configuration

Which Version of POSIX is Supported
===================================

 - Macro: long int _POSIX_VERSION
     This constant represents the version of the POSIX.1 standard to
     which the implementation conforms.  For an implementation
     conforming to the 1990 POSIX.1 standard, the value is the integer
     `199009L'.

     `_POSIX_VERSION' is always defined (in `unistd.h') in any POSIX
     system.

     *Usage Note:* Don't try to test whether the system supports POSIX
     by including `unistd.h' and then checking whether `_POSIX_VERSION'
     is defined.  On a non-POSIX system, this will probably fail
     because there is no `unistd.h'.  We do not know of *any* way you
     can reliably test at compilation time whether your target system
     supports POSIX or whether `unistd.h' exists.

     The GNU C compiler predefines the symbol `__POSIX__' if the target
     system is a POSIX system.  Provided you do not use any other
     compilers on POSIX systems, testing `defined (__POSIX__)' will
     reliably detect such systems.

 - Macro: long int _POSIX2_C_VERSION
     This constant represents the version of the POSIX.2 standard which
     the library and system kernel support.  We don't know what value
     this will be for the first version of the POSIX.2 standard,
     because the value is based on the year and month in which the
     standard is officially adopted.

     The value of this symbol says nothing about the utilities
     installed on the system.

     *Usage Note:* You can use this macro to tell whether a POSIX.1
     system library supports POSIX.2 as well.  Any POSIX.1 system
     contains `unistd.h', so include that file and then test `defined
     (_POSIX2_C_VERSION)'.


File: libc.info,  Node: Sysconf,  Next: Minimums,  Prev: Version Supported,  Up: System Configuration

Using `sysconf'
===============

   When your system has configurable system limits, you can use the
`sysconf' function to find out the value that applies to any particular
machine.  The function and the associated PARAMETER constants are
declared in the header file `unistd.h'.

* Menü:

* Sysconf Definition::        Detailed specifications of `sysconf'.
* Constants for Sysconf::     The list of parameters `sysconf' can read.
* Examples of Sysconf::       How to use `sysconf' and the parameter
				 macros properly together.


File: libc.info,  Node: Sysconf Definition,  Next: Constants for Sysconf,  Up: Sysconf

Definition of `sysconf'
-----------------------

 - Fonction: long int sysconf (int PARAMETER)
     This function is used to inquire about runtime system parameters.
     The PARAMETER argument should be one of the `_SC_' symbols listed
     below.

     The normal return value from `sysconf' is the value you requested.
     A value of `-1' is returned both if the implementation does not
     impose a limit, and in case of an error.

     The following `errno' error conditions are defined for this
     function:

    `EINVAL'
          The value of the PARAMETER is invalid.


File: libc.info,  Node: Constants for Sysconf,  Next: Examples of Sysconf,  Prev: Sysconf Definition,  Up: Sysconf

Constants for `sysconf' Parameters
----------------------------------

   Here are the symbolic constants for use as the PARAMETER argument to
`sysconf'.  The values are all integer constants (more specifically,
enumeration type values).

`_SC_ARG_MAX'
     Inquire about the parameter corresponding to `ARG_MAX'.

`_SC_CHILD_MAX'
     Inquire about the parameter corresponding to `CHILD_MAX'.

`_SC_OPEN_MAX'
     Inquire about the parameter corresponding to `OPEN_MAX'.

`_SC_STREAM_MAX'
     Inquire about the parameter corresponding to `STREAM_MAX'.

`_SC_TZNAME_MAX'
     Inquire about the parameter corresponding to `TZNAME_MAX'.

`_SC_NGROUPS_MAX'
     Inquire about the parameter corresponding to `NGROUPS_MAX'.

`_SC_JOB_CONTROL'
     Inquire about the parameter corresponding to `_POSIX_JOB_CONTROL'.

`_SC_SAVED_IDS'
     Inquire about the parameter corresponding to `_POSIX_SAVED_IDS'.

`_SC_VERSION'
     Inquire about the parameter corresponding to `_POSIX_VERSION'.

`_SC_CLK_TCK'
     Inquire about the parameter corresponding to `CLOCKS_PER_SEC';
     *note Basic CPU Time::..

`_SC_2_C_DEV'
     Inquire about whether the system has the POSIX.2 C compiler
     command, `c89'.

`_SC_2_FORT_DEV'
     Inquire about whether the system has the POSIX.2 Fortran compiler
     command, `fort77'.

`_SC_2_FORT_RUN'
     Inquire about whether the system has the POSIX.2 `asa' command to
     interpret Fortran carriage control.

`_SC_2_LOCALEDEF'
     Inquire about whether the system has the POSIX.2 `localedef'
     command.

`_SC_2_SW_DEV'
     Inquire about whether the system has the POSIX.2 commands `ar',
     `make', and `strip'.

`_SC_BC_BASE_MAX'
     Inquire about the maximum value of `obase' in the `bc' utility.

`_SC_BC_DIM_MAX'
     Inquire about the maximum size of an array in the `bc' utility.

`_SC_BC_SCALE_MAX'
     Inquire about the maximum value of `scale' in the `bc' utility.

`_SC_BC_STRING_MAX'
     Inquire about the maximum size of a string constant in the `bc'
     utility.

`_SC_COLL_WEIGHTS_MAX'
     Inquire about the maximum number of weights that can necessarily
     be used in defining the collating sequence for a locale.

`_SC_EXPR_NEST_MAX'
     Inquire about the maximum number of expressions nested within
     parentheses when using the `expr' utility.

`_SC_LINE_MAX'
     Inquire about the maximum size of a text line that the POSIX.2 text
     utilities can handle.

`_SC_EQUIV_CLASS_MAX'
     Inquire about the maximum number of weights that can be assigned
     to an entry of the `LC_COLLATE' category `order' keyword in a
     locale definition.  The GNU C library does not presently support
     locale definitions.

`_SC_VERSION'
     Inquire about the version number of POSIX.1 that the library and
     kernel support.

`_SC_2_VERSION'
     Inquire about the version number of POSIX.2 that the system
     utilities support.

`_SC_PAGESIZE'
     Inquire about the virtual memory page size of the machine.
     `getpagesize' returns the same value.


File: libc.info,  Node: Examples of Sysconf,  Prev: Constants for Sysconf,  Up: Sysconf

Examples of `sysconf'
---------------------

   We recommend that you first test for a macro definition for the
parameter you are interested in, and call `sysconf' only if the macro
is not defined.  For example, here is how to test whether job control
is supported:

     int
     have_job_control (void)
     {
     #ifdef _POSIX_JOB_CONTROL
       return 1;
     #else
       int value = sysconf (_SC_JOB_CONTROL);
       if (value < 0)
         /* If the system is that badly wedged,
            there's no use trying to go on.  */
         fatal (strerror (errno));
       return value;
     #endif
     }

   Here is how to get the value of a numeric limit:

     int
     get_child_max ()
     {
     #ifdef CHILD_MAX
       return CHILD_MAX;
     #else
       int value = sysconf (_SC_CHILD_MAX);
       if (value < 0)
         fatal (strerror (errno));
       return value;
     #endif
     }


File: libc.info,  Node: Minimums,  Next: Limits for Files,  Prev: Sysconf,  Up: System Configuration

Minimum Values for General Capacity Limits
==========================================

   Here are the names for the POSIX minimum upper bounds for the system
limit parameters.  The significance of these values is that you can
safely push to these limits without checking whether the particular
system you are using can go that far.

`_POSIX_ARG_MAX'
     The value of this macro is the most restrictive limit permitted by
     POSIX for the maximum combined length of the ARGV and ENVIRON
     arguments that can be passed to the `exec' functions.  Its value
     is `4096'.

`_POSIX_CHILD_MAX'
     The value of this macro is the most restrictive limit permitted by
     POSIX for the maximum number of simultaneous processes per real
     user ID.  Its value is `6'.

`_POSIX_NGROUPS_MAX'
     The value of this macro is the most restrictive limit permitted by
     POSIX for the maximum number of supplementary group IDs per
     process.  Its value is `0'.

`_POSIX_OPEN_MAX'
     The value of this macro is the most restrictive limit permitted by
     POSIX for the maximum number of files that a single process can
     have open simultaneously.  Its value is `16'.

`_POSIX_SSIZE_MAX'
     The value of this macro is the most restrictive limit permitted by
     POSIX for the maximum value that can be stored in an object of type
     `ssize_t'.  Its value is `32767'.

`_POSIX_STREAM_MAX'
     The value of this macro is the most restrictive limit permitted by
     POSIX for the maximum number of streams that a single process can
     have open simultaneously.  Its value is `8'.

`_POSIX_TZNAME_MAX'
     The value of this macro is the most restrictive limit permitted by
     POSIX for the maximum length of a time zone name.  Its value is
     `3'.

`_POSIX2_RE_DUP_MAX'
     The value of this macro is the most restrictive limit permitted by
     POSIX for the numbers used in the `\{MIN,MAX\}' construct in a
     regular expression.  Its value is `255'.


File: libc.info,  Node: Limits for Files,  Next: Options for Files,  Prev: Minimums,  Up: System Configuration

Limits on File System Capacity
==============================

   The POSIX.1 standard specifies a number of parameters that describe
the limitations of the file system.  It's possible for the system to
have a fixed, uniform limit for a parameter, but this isn't the usual
case.  On most systems, it's possible for different file systems (and,
for some parameters, even different files) to have different maximum
limits.  For example, this is very likely if you use NFS to mount some
of the file systems from other machines.

   Each of the following macros is defined in `limits.h' only if the
system has a fixed, uniform limit for the parameter in question.  If the
system allows different file systems or files to have different limits,
then the macro is undefined; use `pathconf' or `fpathconf' to find out
the limit that applies to a particular file.  *Note Pathconf::.

   Each parameter also has another macro, with a name starting with
`_POSIX', which gives the lowest value that the limit is allowed to
have on *any* POSIX system.  *Note File Minimums::.

 - Macro: int LINK_MAX
     The uniform system limit (if any) for the number of names for a
     given file.  *Note Hard Links::.

 - Macro: int MAX_CANON
     The uniform system limit (if any) for the amount of text in a line
     of input when input editing is enabled.  *Note Canonical or Not::.

 - Macro: int MAX_INPUT
     The uniform system limit (if any) for the total number of
     characters typed ahead as input.  *Note I/O Queues::.

 - Macro: int NAME_MAX
     The uniform system limit (if any) for the length of a file name
     component.

 - Macro: int PATH_MAX
     The uniform system limit (if any) for the length of an entire file
     name (that is, the argument given to system calls such as `open').

 - Macro: int PIPE_BUF
     The uniform system limit (if any) for the number of bytes that can
     be written atomically to a pipe.  If multiple processes are
     writing to the same pipe simultaneously, output from different
     processes might be interleaved in chunks of this size.  *Note
     Pipes and FIFOs::.

   These are alternative macro names for some of the same information.

 - Macro: int MAXNAMLEN
     This is the BSD name for `NAME_MAX'.  It is defined in `dirent.h'.

 - Macro: int FILENAME_MAX
     The value of this macro is an integer constant expression that
     represents the maximum length of a file name string.  It is
     defined in `stdio.h'.

     Unlike `PATH_MAX', this macro is defined even if there is no actual
     limit imposed.  In such a case, its value is typically a very large
     number.  *This is always the case on the GNU system.*

     *Usage Note:* Don't use `FILENAME_MAX' as the size of an array in
     which to store a file name!  You can't possibly make an array that
     big!  Use dynamic allocation (*note Memory Allocation::.) instead.


File: libc.info,  Node: Options for Files,  Next: File Minimums,  Prev: Limits for Files,  Up: System Configuration

Optional Features in File Support
=================================

   POSIX defines certain system-specific options in the system calls for
operating on files.  Some systems support these options and others do
not.  Since these options are provided in the kernel, not in the
library, simply using the GNU C library does not guarantee any of these
features is supported; it depends on the system you are using.  They can
also vary between file systems on a single machine.

   This section describes the macros you can test to determine whether a
particular option is supported on your machine.  If a given macro is
defined in `unistd.h', then its value says whether the corresponding
feature is supported.  (A value of `-1' indicates no; any other value
indicates yes.)  If the macro is undefined, it means particular files
may or may not support the feature.

   Since all the machines that support the GNU C library also support
NFS, one can never make a general statement about whether all file
systems support the `_POSIX_CHOWN_RESTRICTED' and `_POSIX_NO_TRUNC'
features.  So these names are never defined as macros in the GNU C
library.

 - Macro: int _POSIX_CHOWN_RESTRICTED
     If this option is in effect, the `chown' function is restricted so
     that the only changes permitted to nonprivileged processes is to
     change the group owner of a file to either be the effective group
     ID of the process, or one of its supplementary group IDs.  *Note
     File Owner::.

 - Macro: int _POSIX_NO_TRUNC
     If this option is in effect, file name components longer than
     `NAME_MAX' generate an `ENAMETOOLONG' error.  Otherwise, file name
     components that are too long are silently truncated.

 - Macro: unsigned char _POSIX_VDISABLE
     This option is only meaningful for files that are terminal devices.
     If it is enabled, then handling for special control characters can
     be disabled individually.  *Note Special Characters::.

   If one of these macros is undefined, that means that the option
might be in effect for some files and not for others.  To inquire about
a particular file, call `pathconf' or `fpathconf'.  *Note Pathconf::.


File: libc.info,  Node: File Minimums,  Next: Pathconf,  Prev: Options for Files,  Up: System Configuration

Minimum Values for File System Limits
=====================================

   Here are the names for the POSIX minimum upper bounds for some of the
above parameters.  The significance of these values is that you can
safely push to these limits without checking whether the particular
system you are using can go that far.

`_POSIX_LINK_MAX'
     The most restrictive limit permitted by POSIX for the maximum
     value of a file's link count.  The value of this constant is `8';
     thus, you can always make up to eight names for a file without
     running into a system limit.

`_POSIX_MAX_CANON'
     The most restrictive limit permitted by POSIX for the maximum
     number of bytes in a canonical input line from a terminal device.
     The value of this constant is `255'.

`_POSIX_MAX_INPUT'
     The most restrictive limit permitted by POSIX for the maximum
     number of bytes in a terminal device input queue (or typeahead
     buffer).  *Note Input Modes::.  The value of this constant is
     `255'.

`_POSIX_NAME_MAX'
     The most restrictive limit permitted by POSIX for the maximum
     number of bytes in a file name component.  The value of this
     constant is `14'.

`_POSIX_PATH_MAX'
     The most restrictive limit permitted by POSIX for the maximum
     number of bytes in a file name.  The value of this constant is
     `255'.

`_POSIX_PIPE_BUF'
     The most restrictive limit permitted by POSIX for the maximum
     number of bytes that can be written atomically to a pipe.  The
     value of this constant is `512'.


File: libc.info,  Node: Pathconf,  Next: Utility Limits,  Prev: File Minimums,  Up: System Configuration

Using `pathconf'
================

   When your machine allows different files to have different values
for a file system parameter, you can use the functions in this section
to find out the value that applies to any particular file.

   These functions and the associated constants for the PARAMETER
argument are declared in the header file `unistd.h'.

 - Fonction: long int pathconf (const char *FILENAME, int PARAMETER)
     This function is used to inquire about the limits that apply to
     the file named FILENAME.

     The PARAMETER argument should be one of the `_PC_' constants
     listed below.

     The normal return value from `pathconf' is the value you requested.
     A value of `-1' is returned both if the implementation does not
     impose a limit, and in case of an error.  In the former case,
     `errno' is not set, while in the latter case, `errno' is set to
     indicate the cause of the problem.  So the only way to use this
     function robustly is to store `0' into `errno' just before calling
     it.

     Besides the usual file name errors (*note File Name Errors::.),
     the following error condition is defined for this function:

    `EINVAL'
          The value of PARAMETER is invalid, or the implementation
          doesn't support the PARAMETER for the specific file.

 - Fonction: long int fpathconf (int FILEDES, int PARAMETER)
     This is just like `pathconf' except that an open file descriptor
     is used to specify the file for which information is requested,
     instead of a file name.

     The following `errno' error conditions are defined for this
     function:

    `EBADF'
          The FILEDES argument is not a valid file descriptor.

    `EINVAL'
          The value of PARAMETER is invalid, or the implementation
          doesn't support the PARAMETER for the specific file.

   Here are the symbolic constants that you can use as the PARAMETER
argument to `pathconf' and `fpathconf'.  The values are all integer
constants.

`_PC_LINK_MAX'
     Inquire about the value of `LINK_MAX'.

`_PC_MAX_CANON'
     Inquire about the value of `MAX_CANON'.

`_PC_MAX_INPUT'
     Inquire about the value of `MAX_INPUT'.

`_PC_NAME_MAX'
     Inquire about the value of `NAME_MAX'.

`_PC_PATH_MAX'
     Inquire about the value of `PATH_MAX'.

`_PC_PIPE_BUF'
     Inquire about the value of `PIPE_BUF'.

`_PC_CHOWN_RESTRICTED'
     Inquire about the value of `_POSIX_CHOWN_RESTRICTED'.

`_PC_NO_TRUNC'
     Inquire about the value of `_POSIX_NO_TRUNC'.

`_PC_VDISABLE'
     Inquire about the value of `_POSIX_VDISABLE'.


File: libc.info,  Node: Utility Limits,  Next: Utility Minimums,  Prev: Pathconf,  Up: System Configuration

Utility Program Capacity Limits
===============================

   The POSIX.2 standard specifies certain system limits that you can
access through `sysconf' that apply to utility behavior rather than the
behavior of the library or the operating system.

   The GNU C library defines macros for these limits, and `sysconf'
returns values for them if you ask; but these values convey no
meaningful information.  They are simply the smallest values that
POSIX.2 permits.

 - Macro: int BC_BASE_MAX
     The largest value of `obase' that the `bc' utility is guaranteed
     to support.

 - Macro: int BC_SCALE_MAX
     The largest value of `scale' that the `bc' utility is guaranteed
     to support.

 - Macro: int BC_DIM_MAX
     The largest number of elements in one array that the `bc' utility
     is guaranteed to support.

 - Macro: int BC_STRING_MAX
     The largest number of characters in one string constant that the
     `bc' utility is guaranteed to support.

 - Macro: int BC_DIM_MAX
     The largest number of elements in one array that the `bc' utility
     is guaranteed to support.

 - Macro: int COLL_WEIGHTS_MAX
     The largest number of weights that can necessarily be used in
     defining the collating sequence for a locale.

 - Macro: int EXPR_NEST_MAX
     The maximum number of expressions that can be nested within
     parenthesis by the `expr' utility.

 - Macro: int LINE_MAX
     The largest text line that the text-oriented POSIX.2 utilities can
     support.  (If you are using the GNU versions of these utilities,
     then there is no actual limit except that imposed by the available
     virtual memory, but there is no way that the library can tell you
     this.)

 - Macro: int EQUIV_CLASS_MAX
     The maximum number of weights that can be assigned to an entry of
     the `LC_COLLATE' category `order' keyword in a locale definition.
     The GNU C library does not presently support locale definitions.


File: libc.info,  Node: Utility Minimums,  Next: String Parameters,  Prev: Utility Limits,  Up: System Configuration

Minimum Values for Utility Limits
=================================

`_POSIX2_BC_BASE_MAX'
     The most restrictive limit permitted by POSIX.2 for the maximum
     value of `obase' in the `bc' utility.  Its value is `99'.

`_POSIX2_BC_DIM_MAX'
     The most restrictive limit permitted by POSIX.2 for the maximum
     size of an array in the `bc' utility.  Its value is `2048'.

`_POSIX2_BC_SCALE_MAX'
     The most restrictive limit permitted by POSIX.2 for the maximum
     value of `scale' in the `bc' utility.  Its value is `99'.

`_POSIX2_BC_STRING_MAX'
     The most restrictive limit permitted by POSIX.2 for the maximum
     size of a string constant in the `bc' utility.  Its value is
     `1000'.

`_POSIX2_COLL_WEIGHTS_MAX'
     The most restrictive limit permitted by POSIX.2 for the maximum
     number of weights that can necessarily be used in defining the
     collating sequence for a locale.  Its value is `2'.

`_POSIX2_EXPR_NEST_MAX'
     The most restrictive limit permitted by POSIX.2 for the maximum
     number of expressions nested within parenthesis when using the
     `expr' utility.  Its value is `32'.

`_POSIX2_LINE_MAX'
     The most restrictive limit permitted by POSIX.2 for the maximum
     size of a text line that the text utilities can handle.  Its value
     is `2048'.

`_POSIX2_EQUIV_CLASS_MAX'
     The most restrictive limit permitted by POSIX.2 for the maximum
     number of weights that can be assigned to an entry of the
     `LC_COLLATE' category `order' keyword in a locale definition.  Its
     value is `2'.  The GNU C library does not presently support locale
     definitions.


File: libc.info,  Node: String Parameters,  Prev: Utility Minimums,  Up: System Configuration

String-Valued Parameters
========================

   POSIX.2 defines a way to get string-valued parameters from the
operating system with the function `confstr':

 - Fonction: size_t confstr (int PARAMETER, char *BUF, size_t LEN)
     This function reads the value of a string-valued system parameter,
     storing the string into LEN bytes of memory space starting at BUF.
     The PARAMETER argument should be one of the `_CS_' symbols listed
     below.

     The normal return value from `confstr' is the length of the string
     value that you asked for.  If you supply a null pointer for BUF,
     then `confstr' does not try to store the string; it just returns
     its length.  A value of `0' indicates an error.

     If the string you asked for is too long for the buffer (that is,
     longer than `LEN - 1'), then `confstr' stores just that much
     (leaving room for the terminating null character).  You can tell
     that this has happened because `confstr' returns a value greater
     than or equal to LEN.

     The following `errno' error conditions are defined for this
     function:

    `EINVAL'
          The value of the PARAMETER is invalid.

   Currently there is just one parameter you can read with `confstr':

`_CS_PATH'
     This parameter's value is the recommended default path for
     searching for executable files.  This is the path that a user has
     by default just after logging in.

   The way to use `confstr' without any arbitrary limit on string size
is to call it twice: first call it to get the length, allocate the
buffer accordingly, and then call `confstr' again to fill the buffer,
like this:

     char *
     get_default_path (void)
     {
       size_t len = confstr (_CS_PATH, NULL, 0);
       char *buffer = (char *) xmalloc (len);
     
       if (confstr (_CS_PATH, buf, len + 1) == 0)
         {
           free (buffer);
           return NULL;
         }
     
       return buffer;
     }


File: libc.info,  Node: Language Features,  Next: Library Summary,  Prev: System Configuration,  Up: Top

C Language Facilities in the Library
************************************

   Some of the facilities implemented by the C library really should be
thought of as parts of the C language itself.  These facilities ought to
be documented in the C Language Manual, not in the library manual; but
since we don't have the language manual yet, and documentation for these
features has been written, we are publishing it here.

* Menü:

* Consistency Checking::        Using `assert' to abort if
				 something "impossible" happens.
* Variadic Functions::          Defining functions with varying numbers
                                 of args.
* Null Pointer Constant::       The macro `NULL'.
* Important Data Types::        Data types for object sizes.
* Data Type Measurements::      Parameters of data type representations.


File: libc.info,  Node: Consistency Checking,  Next: Variadic Functions,  Up: Language Features

Explicitly Checking Internal Consistency
========================================

   When you're writing a program, it's often a good idea to put in
checks at strategic places for "impossible" errors or violations of
basic assumptions.  These kinds of checks are helpful in debugging
problems with the interfaces between different parts of the program,
for example.

   The `assert' macro, defined in the header file `assert.h', provides
a convenient way to abort the program while printing a message about
where in the program the error was detected.

   Once you think your program is debugged, you can disable the error
checks performed by the `assert' macro by recompiling with the macro
`NDEBUG' defined.  This means you don't actually have to change the
program source code to disable these checks.

   But disabling these consistency checks is undesirable unless they
make the program significantly slower.  All else being equal, more error
checking is good no matter who is running the program.  A wise user
would rather have a program crash, visibly, than have it return nonsense
without indicating anything might be wrong.

 - Macro: void assert (int EXPRESSION)
     Verify the programmer's belief that EXPRESSION should be nonzero
     at this point in the program.

     If `NDEBUG' is not defined, `assert' tests the value of
     EXPRESSION.  If it is false (zero), `assert' aborts the program
     (*note Aborting a Program::.) after printing a message of the form:

          `FILE':LINENUM: FUNCTION: Assertion `EXPRESSION' failed.

     on the standard error stream `stderr' (*note Standard Streams::.).
     The filename and line number are taken from the C preprocessor
     macros `__FILE__' and `__LINE__' and specify where the call to
     `assert' was written.  When using the GNU C compiler, the name of
     the function which calls `assert' is taken from the built-in
     variable `__PRETTY_FUNCTION__'; with older compilers, the function
     name and following colon are omitted.

     If the preprocessor macro `NDEBUG' is defined before `assert.h' is
     included, the `assert' macro is defined to do absolutely nothing.

     *Warning:* Even the argument expression EXPRESSION is not
     evaluated if `NDEBUG' is in effect.  So never use `assert' with
     arguments that involve side effects.  For example, `assert (++i >
     0);' is a bad idea, because `i' will not be incremented if
     `NDEBUG' is defined.

   Sometimes the "impossible" condition you want to check for is an
error return from an operating system function.  Then it is useful to
display not only where the program crashes, but also what error was
returned.  The `assert_perror' macro makes this easy.

 - Macro: void assert_perror (int ERRNUM)
     Similar to `assert', but verifies that ERRNUM is zero.

     If `NDEBUG' is defined, `assert_perror' tests the value of ERRNUM.
     If it is nonzero, `assert_perror' aborts the program after a
     printing a message of the form:

          `FILE':LINENUM: FUNCTION: ERROR TEXT

     on the standard error stream.  The file name, line number, and
     function name are as for `assert'.  The error text is the result of
     `strerror (ERRNUM)'.  *Note Error Messages::.

     Like `assert', if `NDEBUG' is defined before `assert.h' is
     included, the `assert_perror' macro does absolutely nothing.  It
     does not evaluate the argument, so ERRNUM should not have any side
     effects.  It is best for ERRNUM to be a just simple variable
     reference; often it will be `errno'.

     This macro is a GNU extension.

   *Usage note:* The `assert' facility is designed for detecting
*internal inconsistency*; it is not suitable for reporting invalid
input or improper usage by *the user* of the program.

   The information in the diagnostic messages printed by the `assert'
macro is intended to help you, the programmer, track down the cause of a
bug, but is not really useful for telling a user of your program why his
or her input was invalid or why a command could not be carried out.  So
you can't use `assert' or `assert_perror' to print the error messages
for these eventualities.

   What's more, your program should not abort when given invalid input,
as `assert' would do--it should exit with nonzero status (*note Exit
Status::.) after printing its error messages, or perhaps read another
command or move on to the next input file.

   *Note Error Messages::, for information on printing error messages
for problems that *do not* represent bugs in the program.


File: libc.info,  Node: Variadic Functions,  Next: Null Pointer Constant,  Prev: Consistency Checking,  Up: Language Features

Variadic Functions
==================

   ISO C defines a syntax for declaring a function to take a variable
number or type of arguments.  (Such functions are referred to as
"varargs functions" or "variadic functions".)  However, the language
itself provides no mechanism for such functions to access their
non-required arguments; instead, you use the variable arguments macros
defined in `stdarg.h'.

   This section describes how to declare variadic functions, how to
write them, and how to call them properly.

   *Compatibility Note:* Many older C dialects provide a similar, but
incompatible, mechanism for defining functions with variable numbers of
arguments, using `varargs.h'.

* Menü:

* Why Variadic::                Reasons for making functions take
                                 variable arguments.
* How Variadic::                How to define and call variadic functions.
* Variadic Example::            A complete example.


File: libc.info,  Node: Why Variadic,  Next: How Variadic,  Up: Variadic Functions

Why Variadic Functions are Used
-------------------------------

   Ordinary C functions take a fixed number of arguments.  When you
define a function, you specify the data type for each argument.  Every
call to the function should supply the expected number of arguments,
with types that can be converted to the specified ones.  Thus, if the
function `foo' is declared with `int foo (int, char *);' then you must
call it with two arguments, a number (any kind will do) and a string
pointer.

   But some functions perform operations that can meaningfully accept an
unlimited number of arguments.

   In some cases a function can handle any number of values by
operating on all of them as a block.  For example, consider a function
that allocates a one-dimensional array with `malloc' to hold a
specified set of values.  This operation makes sense for any number of
values, as long as the length of the array corresponds to that number.
Without facilities for variable arguments, you would have to define a
separate function for each possible array size.

   The library function `printf' (*note Formatted Output::.) is an
example of another class of function where variable arguments are
useful.  This function prints its arguments (which can vary in type as
well as number) under the control of a format template string.

   These are good reasons to define a "variadic" function which can
handle as many arguments as the caller chooses to pass.

   Some functions such as `open' take a fixed set of arguments, but
occasionally ignore the last few.  Strict adherence to ISO C requires
these functions to be defined as variadic; in practice, however, the GNU
C compiler and most other C compilers let you define such a function to
take a fixed set of arguments--the most it can ever use--and then only
*declare* the function as variadic (or not declare its arguments at
all!).


File: libc.info,  Node: How Variadic,  Next: Variadic Example,  Prev: Why Variadic,  Up: Variadic Functions

How Variadic Functions are Defined and Used
-------------------------------------------

   Defining and using a variadic function involves three steps:

   * *Define* the function as variadic, using an ellipsis (`...') in
     the argument list, and using special macros to access the variable
     arguments.  *Note Receiving Arguments::.

   * *Declare* the function as variadic, using a prototype with an
     ellipsis (`...'), in all the files which call it.  *Note Variadic
     Prototypes::.

   * *Call* the function by writing the fixed arguments followed by the
     additional variable arguments.  *Note Calling Variadics::.

* Menü:

* Variadic Prototypes::  How to make a prototype for a function
			  with variable arguments.
* Receiving Arguments::  Steps you must follow to access the
			  optional argument values.
* How Many Arguments::   How to decide whether there are more arguments.
* Calling Variadics::    Things you need to know about calling
			  variable arguments functions.
* Argument Macros::      Detailed specification of the macros
        		  for accessing variable arguments.
* Old Varargs::		 The pre-ISO way of defining variadic functions.


File: libc.info,  Node: Variadic Prototypes,  Next: Receiving Arguments,  Up: How Variadic

Syntax for Variable Arguments
.............................

   A function that accepts a variable number of arguments must be
declared with a prototype that says so.   You write the fixed arguments
as usual, and then tack on `...' to indicate the possibility of
additional arguments.  The syntax of ISO C requires at least one fixed
argument before the `...'.  For example,

     int
     func (const char *a, int b, ...)
     {
       ...
     }

outlines a definition of a function `func' which returns an `int' and
takes two required arguments, a `const char *' and an `int'.  These are
followed by any number of anonymous arguments.

   *Portability note:* For some C compilers, the last required argument
must not be declared `register' in the function definition.
Furthermore, this argument's type must be "self-promoting": that is,
the default promotions must not change its type.  This rules out array
and function types, as well as `float', `char' (whether signed or not)
and `short int' (whether signed or not).  This is actually an ISO C
requirement.


File: libc.info,  Node: Receiving Arguments,  Next: How Many Arguments,  Prev: Variadic Prototypes,  Up: How Variadic

Receiving the Argument Values
.............................

   Ordinary fixed arguments have individual names, and you can use these
names to access their values.  But optional arguments have no
names--nothing but `...'.  How can you access them?

   The only way to access them is sequentially, in the order they were
written, and you must use special macros from `stdarg.h' in the
following three step process:

  1. You initialize an argument pointer variable of type `va_list' using
     `va_start'.  The argument pointer when initialized points to the
     first optional argument.

  2. You access the optional arguments by successive calls to `va_arg'.
     The first call to `va_arg' gives you the first optional argument,
     the next call gives you the second, and so on.

     You can stop at any time if you wish to ignore any remaining
     optional arguments.  It is perfectly all right for a function to
     access fewer arguments than were supplied in the call, but you
     will get garbage values if you try to access too many arguments.

  3. You indicate that you are finished with the argument pointer
     variable by calling `va_end'.

     (In practice, with most C compilers, calling `va_end' does nothing
     and you do not really need to call it.  This is always true in the
     GNU C compiler.  But you might as well call `va_end' just in case
     your program is someday compiled with a peculiar compiler.)

   *Note Argument Macros::, for the full definitions of `va_start',
`va_arg' and `va_end'.

   Steps 1 and 3 must be performed in the function that accepts the
optional arguments.  However, you can pass the `va_list' variable as an
argument to another function and perform all or part of step 2 there.

   You can perform the entire sequence of the three steps multiple times
within a single function invocation.  If you want to ignore the optional
arguments, you can do these steps zero times.

   You can have more than one argument pointer variable if you like.
You can initialize each variable with `va_start' when you wish, and
then you can fetch arguments with each argument pointer as you wish.
Each argument pointer variable will sequence through the same set of
argument values, but at its own pace.

   *Portability note:* With some compilers, once you pass an argument
pointer value to a subroutine, you must not keep using the same
argument pointer value after that subroutine returns.  For full
portability, you should just pass it to `va_end'.  This is actually an
ISO C requirement, but most ANSI C compilers work happily regardless.


File: libc.info,  Node: How Many Arguments,  Next: Calling Variadics,  Prev: Receiving Arguments,  Up: How Variadic

How Many Arguments Were Supplied
................................

   There is no general way for a function to determine the number and
type of the optional arguments it was called with.  So whoever designs
the function typically designs a convention for the caller to tell it
how many arguments it has, and what kind.  It is up to you to define an
appropriate calling convention for each variadic function, and write all
calls accordingly.

   One kind of calling convention is to pass the number of optional
arguments as one of the fixed arguments.  This convention works provided
all of the optional arguments are of the same type.

   A similar alternative is to have one of the required arguments be a
bit mask, with a bit for each possible purpose for which an optional
argument might be supplied.  You would test the bits in a predefined
sequence; if the bit is set, fetch the value of the next argument,
otherwise use a default value.

   A required argument can be used as a pattern to specify both the
number and types of the optional arguments.  The format string argument
to `printf' is one example of this (*note Formatted Output
Functions::.).

   Another possibility is to pass an "end marker" value as the last
optional argument.  For example, for a function that manipulates an
arbitrary number of pointer arguments, a null pointer might indicate the
end of the argument list.  (This assumes that a null pointer isn't
otherwise meaningful to the function.)  The `execl' function works in
just this way; see *Note Executing a File::.


File: libc.info,  Node: Calling Variadics,  Next: Argument Macros,  Prev: How Many Arguments,  Up: How Variadic

Calling Variadic Functions
..........................

   You don't have to write anything special when you call a variadic
function.  Just write the arguments (required arguments, followed by
optional ones) inside parentheses, separated by commas, as usual.  But
you should prepare by declaring the function with a prototype, and you
must know how the argument values are converted.

   In principle, functions that are *defined* to be variadic must also
be *declared* to be variadic using a function prototype whenever you
call them.  (*Note Variadic Prototypes::, for how.)  This is because
some C compilers use a different calling convention to pass the same set
of argument values to a function depending on whether that function
takes variable arguments or fixed arguments.

   In practice, the GNU C compiler always passes a given set of argument
types in the same way regardless of whether they are optional or
required.  So, as long as the argument types are self-promoting, you can
safely omit declaring them.  Usually it is a good idea to declare the
argument types for variadic functions, and indeed for all functions.
But there are a few functions which it is extremely convenient not to
have to declare as variadic--for example, `open' and `printf'.

   Since the prototype doesn't specify types for optional arguments, in
a call to a variadic function the "default argument promotions" are
performed on the optional argument values.  This means the objects of
type `char' or `short int' (whether signed or not) are promoted to
either `int' or `unsigned int', as appropriate; and that objects of
type `float' are promoted to type `double'.  So, if the caller passes a
`char' as an optional argument, it is promoted to an `int', and the
function should get it with `va_arg (AP, int)'.

   Conversion of the required arguments is controlled by the function
prototype in the usual way: the argument expression is converted to the
declared argument type as if it were being assigned to a variable of
that type.


File: libc.info,  Node: Argument Macros,  Next: Old Varargs,  Prev: Calling Variadics,  Up: How Variadic

Argument Access Macros
......................

   Here are descriptions of the macros used to retrieve variable
arguments.  These macros are defined in the header file `stdarg.h'.

 - Data Type: va_list
     The type `va_list' is used for argument pointer variables.

 - Macro: void va_start (va_list AP, LAST-REQUIRED)
     This macro initializes the argument pointer variable AP to point
     to the first of the optional arguments of the current function;
     LAST-REQUIRED must be the last required argument to the function.

     *Note Old Varargs::, for an alternate definition of `va_start'
     found in the header file `varargs.h'.

 - Macro: TYPE va_arg (va_list AP, TYPE)
     The `va_arg' macro returns the value of the next optional argument,
     and modifies the value of AP to point to the subsequent argument.
     Thus, successive uses of `va_arg' return successive optional
     arguments.

     The type of the value returned by `va_arg' is TYPE as specified in
     the call.  TYPE must be a self-promoting type (not `char' or
     `short int' or `float') that matches the type of the actual
     argument.

 - Macro: void va_end (va_list AP)
     This ends the use of AP.  After a `va_end' call, further `va_arg'
     calls with the same AP may not work.  You should invoke `va_end'
     before returning from the function in which `va_start' was invoked
     with the same AP argument.

     In the GNU C library, `va_end' does nothing, and you need not ever
     use it except for reasons of portability.



File: libc.info,  Node: Variadic Example,  Prev: How Variadic,  Up: Variadic Functions

Example of a Variadic Function
------------------------------

   Here is a complete sample function that accepts a variable number of
arguments.  The first argument to the function is the count of remaining
arguments, which are added up and the result returned.  While trivial,
this function is sufficient to illustrate how to use the variable
arguments facility.

     #include <stdarg.h>
     #include <stdio.h>
     
     int
     add_em_up (int count,...)
     {
       va_list ap;
       int i, sum;
     
       va_start (ap, count);         /* Initialize the argument list. */
     
       sum = 0;
       for (i = 0; i < count; i++)
         sum += va_arg (ap, int);    /* Get the next argument value. */
     
       va_end (ap);                  /* Clean up. */
       return sum;
     }
     
     int
     main (void)
     {
       /* This call prints 16. */
       printf ("%d\n", add_em_up (3, 5, 5, 6));
     
       /* This call prints 55. */
       printf ("%d\n", add_em_up (10, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10));
     
       return 0;
     }


File: libc.info,  Node: Old Varargs,  Prev: Argument Macros,  Up: How Variadic

Old-Style Variadic Functions
............................

   Before ISO C, programmers used a slightly different facility for
writing variadic functions.  The GNU C compiler still supports it;
currently, it is more portable than the ISO C facility, since support
for ISO C is still not universal.  The header file which defines the
old-fashioned variadic facility is called `varargs.h'.

   Using `varargs.h' is almost the same as using `stdarg.h'.  There is
no difference in how you call a variadic function; *Note Calling
Variadics::.  The only difference is in how you define them.  First of
all, you must use old-style non-prototype syntax, like this:

     tree
     build (va_alist)
          va_dcl
     {

   Secondly, you must give `va_start' just one argument, like this:

       va_list p;
       va_start (p);

   These are the special macros used for defining old-style variadic
functions:

 - Macro: va_alist
     This macro stands for the argument name list required in a variadic
     function.

 - Macro: va_dcl
     This macro declares the implicit argument or arguments for a
     variadic function.

 - Macro: void va_start (va_list AP)
     This macro, as defined in `varargs.h', initializes the argument
     pointer variable AP to point to the first argument of the current
     function.

   The other argument macros, `va_arg' and `va_end', are the same in
`varargs.h' as in `stdarg.h'; see *Note Argument Macros:: for details.

   It does not work to include both `varargs.h' and `stdarg.h' in the
same compilation; they define `va_start' in conflicting ways.


File: libc.info,  Node: Null Pointer Constant,  Next: Important Data Types,  Prev: Variadic Functions,  Up: Language Features

Null Pointer Constant
=====================

   The null pointer constant is guaranteed not to point to any real
object.  You can assign it to any pointer variable since it has type
`void *'.  The preferred way to write a null pointer constant is with
`NULL'.

 - Macro: void * NULL
     This is a null pointer constant.

   You can also use `0' or `(void *)0' as a null pointer constant, but
using `NULL' is cleaner because it makes the purpose of the constant
more evident.

   If you use the null pointer constant as a function argument, then for
complete portability you should make sure that the function has a
prototype declaration.  Otherwise, if the target machine has two
different pointer representations, the compiler won't know which
representation to use for that argument.  You can avoid the problem by
explicitly casting the constant to the proper pointer type, but we
recommend instead adding a prototype for the function you are calling.

