This is libc.info, produced by makeinfo version 4.6 from 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.10, last updated 2001-07-06, of `The GNU C Library Reference Manual', for Version 2.3.x. Copyright (C) 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2001, 2002 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.  File: libc.info, Node: BSD Random, Next: SVID Random, Prev: ISO Random, Up: Pseudo-Random Numbers BSD Random Number Functions --------------------------- This section describes a set of random number generation functions that are derived from BSD. There is no advantage to using these functions with the GNU C library; we support them for BSD compatibility only. The prototypes for these functions are in `stdlib.h'. - Function: long int random (void) This function returns the next pseudo-random number in the sequence. The value returned ranges from `0' to `RAND_MAX'. *Note:* Temporarily this function was defined to return a `int32_t' value to indicate that the return value always contains 32 bits even if `long int' is wider. The standard demands it differently. Users must always be aware of the 32-bit limitation, though. - Function: void srandom (unsigned int SEED) The `srandom' function sets the state of the random number generator based on the integer SEED. If you supply a SEED value of `1', this will cause `random' to reproduce the default set of random numbers. To produce a different set of pseudo-random numbers each time your program runs, do `srandom (time (0))'. - Function: void * initstate (unsigned int SEED, void *STATE, size_t SIZE) The `initstate' function is used to initialize the random number generator state. The argument STATE is an array of SIZE bytes, used to hold the state information. It is initialized based on SEED. The size must be between 8 and 256 bytes, and should be a power of two. The bigger the STATE array, the better. The return value is the previous value of the state information array. You can use this value later as an argument to `setstate' to restore that state. - Function: void * setstate (void *STATE) The `setstate' function restores the random number state information STATE. The argument must have been the result of a previous call to INITSTATE or SETSTATE. The return value is the previous value of the state information array. You can use this value later as an argument to `setstate' to restore that state. If the function fails the return value is `NULL'. The four functions described so far in this section all work on a state which is shared by all threads. The state is not directly accessible to the user and can only be modified by these functions. This makes it hard to deal with situations where each thread should have its own pseudo-random number generator. The GNU C library contains four additional functions which contain the state as an explicit parameter and therefore make it possible to handle thread-local PRNGs. Beside this there are no difference. In fact, the four functions already discussed are implemented internally using the following interfaces. The `stdlib.h' header contains a definition of the following type: - Data Type: struct random_data Objects of type `struct random_data' contain the information necessary to represent the state of the PRNG. Although a complete definition of the type is present the type should be treated as opaque. The functions modifying the state follow exactly the already described functions. - Function: int random_r (struct random_data *restrict BUF, int32_t *restrict RESULT) The `random_r' function behaves exactly like the `random' function except that it uses and modifies the state in the object pointed to by the first parameter instead of the global state. - Function: int srandom_r (unsigned int SEED, struct random_data *BUF) The `srandom_r' function behaves exactly like the `srandom' function except that it uses and modifies the state in the object pointed to by the second parameter instead of the global state. - Function: int initstate_r (unsigned int SEED, char *restrict STATEBUF, size_t STATELEN, struct random_data *restrict BUF) The `initstate_r' function behaves exactly like the `initstate' function except that it uses and modifies the state in the object pointed to by the fourth parameter instead of the global state. - Function: int setstate_r (char *restrict STATEBUF, struct random_data *restrict BUF) The `setstate_r' function behaves exactly like the `setstate' function except that it uses and modifies the state in the object pointed to by the first parameter instead of the global state.  File: libc.info, Node: SVID Random, Prev: BSD Random, Up: Pseudo-Random Numbers SVID Random Number Function --------------------------- The C library on SVID systems contains yet another kind of random number generator functions. They use a state of 48 bits of data. The user can choose among a collection of functions which return the random bits in different forms. Generally there are two kinds of function. The first uses a state of the random number generator which is shared among several functions and by all threads of the process. The second requires the user to handle the state. All functions have in common that they use the same congruential formula with the same constants. The formula is Y = (a * X + c) mod m where X is the state of the generator at the beginning and Y the state at the end. `a' and `c' are constants determining the way the generator works. By default they are a = 0x5DEECE66D = 25214903917 c = 0xb = 11 but they can also be changed by the user. `m' is of course 2^48 since the state consists of a 48-bit array. The prototypes for these functions are in `stdlib.h'. - Function: double drand48 (void) This function returns a `double' value in the range of `0.0' to `1.0' (exclusive). The random bits are determined by the global state of the random number generator in the C library. Since the `double' type according to IEEE 754 has a 52-bit mantissa this means 4 bits are not initialized by the random number generator. These are (of course) chosen to be the least significant bits and they are initialized to `0'. - Function: double erand48 (unsigned short int XSUBI[3]) This function returns a `double' value in the range of `0.0' to `1.0' (exclusive), similarly to `drand48'. The argument is an array describing the state of the random number generator. This function can be called subsequently since it updates the array to guarantee random numbers. The array should have been initialized before initial use to obtain reproducible results. - Function: long int lrand48 (void) The `lrand48' function returns an integer value in the range of `0' to `2^31' (exclusive). Even if the size of the `long int' type can take more than 32 bits, no higher numbers are returned. The random bits are determined by the global state of the random number generator in the C library. - Function: long int nrand48 (unsigned short int XSUBI[3]) This function is similar to the `lrand48' function in that it returns a number in the range of `0' to `2^31' (exclusive) but the state of the random number generator used to produce the random bits is determined by the array provided as the parameter to the function. The numbers in the array are updated afterwards so that subsequent calls to this function yield different results (as is expected of a random number generator). The array should have been initialized before the first call to obtain reproducible results. - Function: long int mrand48 (void) The `mrand48' function is similar to `lrand48'. The only difference is that the numbers returned are in the range `-2^31' to `2^31' (exclusive). - Function: long int jrand48 (unsigned short int XSUBI[3]) The `jrand48' function is similar to `nrand48'. The only difference is that the numbers returned are in the range `-2^31' to `2^31' (exclusive). For the `xsubi' parameter the same requirements are necessary. The internal state of the random number generator can be initialized in several ways. The methods differ in the completeness of the information provided. - Function: void srand48 (long int SEEDVAL) The `srand48' function sets the most significant 32 bits of the internal state of the random number generator to the least significant 32 bits of the SEEDVAL parameter. The lower 16 bits are initialized to the value `0x330E'. Even if the `long int' type contains more than 32 bits only the lower 32 bits are used. Owing to this limitation, initialization of the state of this function is not very useful. But it makes it easy to use a construct like `srand48 (time (0))'. A side-effect of this function is that the values `a' and `c' from the internal state, which are used in the congruential formula, are reset to the default values given above. This is of importance once the user has called the `lcong48' function (see below). - Function: unsigned short int * seed48 (unsigned short int SEED16V[3]) The `seed48' function initializes all 48 bits of the state of the internal random number generator from the contents of the parameter SEED16V. Here the lower 16 bits of the first element of SEE16V initialize the least significant 16 bits of the internal state, the lower 16 bits of `SEED16V[1]' initialize the mid-order 16 bits of the state and the 16 lower bits of `SEED16V[2]' initialize the most significant 16 bits of the state. Unlike `srand48' this function lets the user initialize all 48 bits of the state. The value returned by `seed48' is a pointer to an array containing the values of the internal state before the change. This might be useful to restart the random number generator at a certain state. Otherwise the value can simply be ignored. As for `srand48', the values `a' and `c' from the congruential formula are reset to the default values. There is one more function to initialize the random number generator which enables you to specify even more information by allowing you to change the parameters in the congruential formula. - Function: void lcong48 (unsigned short int PARAM[7]) The `lcong48' function allows the user to change the complete state of the random number generator. Unlike `srand48' and `seed48', this function also changes the constants in the congruential formula. From the seven elements in the array PARAM the least significant 16 bits of the entries `PARAM[0]' to `PARAM[2]' determine the initial state, the least significant 16 bits of `PARAM[3]' to `PARAM[5]' determine the 48 bit constant `a' and `PARAM[6]' determines the 16-bit value `c'. All the above functions have in common that they use the global parameters for the congruential formula. In multi-threaded programs it might sometimes be useful to have different parameters in different threads. For this reason all the above functions have a counterpart which works on a description of the random number generator in the user-supplied buffer instead of the global state. Please note that it is no problem if several threads use the global state if all threads use the functions which take a pointer to an array containing the state. The random numbers are computed following the same loop but if the state in the array is different all threads will obtain an individual random number generator. The user-supplied buffer must be of type `struct drand48_data'. This type should be regarded as opaque and not manipulated directly. - Function: int drand48_r (struct drand48_data *BUFFER, double *RESULT) This function is equivalent to the `drand48' function with the difference that it does not modify the global random number generator parameters but instead the parameters in the buffer supplied through the pointer BUFFER. The random number is returned in the variable pointed to by RESULT. The return value of the function indicates whether the call succeeded. If the value is less than `0' an error occurred and ERRNO is set to indicate the problem. This function is a GNU extension and should not be used in portable programs. - Function: int erand48_r (unsigned short int XSUBI[3], struct drand48_data *BUFFER, double *RESULT) The `erand48_r' function works like `erand48', but in addition it takes an argument BUFFER which describes the random number generator. The state of the random number generator is taken from the `xsubi' array, the parameters for the congruential formula from the global random number generator data. The random number is returned in the variable pointed to by RESULT. The return value is non-negative if the call succeeded. This function is a GNU extension and should not be used in portable programs. - Function: int lrand48_r (struct drand48_data *BUFFER, double *RESULT) This function is similar to `lrand48', but in addition it takes a pointer to a buffer describing the state of the random number generator just like `drand48'. If the return value of the function is non-negative the variable pointed to by RESULT contains the result. Otherwise an error occurred. This function is a GNU extension and should not be used in portable programs. - Function: int nrand48_r (unsigned short int XSUBI[3], struct drand48_data *BUFFER, long int *RESULT) The `nrand48_r' function works like `nrand48' in that it produces a random number in the range `0' to `2^31'. But instead of using the global parameters for the congruential formula it uses the information from the buffer pointed to by BUFFER. The state is described by the values in XSUBI. If the return value is non-negative the variable pointed to by RESULT contains the result. This function is a GNU extension and should not be used in portable programs. - Function: int mrand48_r (struct drand48_data *BUFFER, double *RESULT) This function is similar to `mrand48' but like the other reentrant functions it uses the random number generator described by the value in the buffer pointed to by BUFFER. If the return value is non-negative the variable pointed to by RESULT contains the result. This function is a GNU extension and should not be used in portable programs. - Function: int jrand48_r (unsigned short int XSUBI[3], struct drand48_data *BUFFER, long int *RESULT) The `jrand48_r' function is similar to `jrand48'. Like the other reentrant functions of this function family it uses the congruential formula parameters from the buffer pointed to by BUFFER. If the return value is non-negative the variable pointed to by RESULT contains the result. This function is a GNU extension and should not be used in portable programs. Before any of the above functions are used the buffer of type `struct drand48_data' should be initialized. The easiest way to do this is to fill the whole buffer with null bytes, e.g. by memset (buffer, '\0', sizeof (struct drand48_data)); Using any of the reentrant functions of this family now will automatically initialize the random number generator to the default values for the state and the parameters of the congruential formula. The other possibility is to use any of the functions which explicitly initialize the buffer. Though it might be obvious how to initialize the buffer from looking at the parameter to the function, it is highly recommended to use these functions since the result might not always be what you expect. - Function: int srand48_r (long int SEEDVAL, struct drand48_data *BUFFER) The description of the random number generator represented by the information in BUFFER is initialized similarly to what the function `srand48' does. The state is initialized from the parameter SEEDVAL and the parameters for the congruential formula are initialized to their default values. If the return value is non-negative the function call succeeded. This function is a GNU extension and should not be used in portable programs. - Function: int seed48_r (unsigned short int SEED16V[3], struct drand48_data *BUFFER) This function is similar to `srand48_r' but like `seed48' it initializes all 48 bits of the state from the parameter SEED16V. If the return value is non-negative the function call succeeded. It does not return a pointer to the previous state of the random number generator like the `seed48' function does. If the user wants to preserve the state for a later re-run s/he can copy the whole buffer pointed to by BUFFER. This function is a GNU extension and should not be used in portable programs. - Function: int lcong48_r (unsigned short int PARAM[7], struct drand48_data *BUFFER) This function initializes all aspects of the random number generator described in BUFFER with the data in PARAM. Here it is especially true that the function does more than just copying the contents of PARAM and BUFFER. More work is required and therefore it is important to use this function rather than initializing the random number generator directly. If the return value is non-negative the function call succeeded. This function is a GNU extension and should not be used in portable programs.  File: libc.info, Node: FP Function Optimizations, Prev: Pseudo-Random Numbers, Up: Mathematics Is Fast Code or Small Code preferred? ===================================== If an application uses many floating point functions it is often the case that the cost of the function calls themselves is not negligible. Modern processors can often execute the operations themselves very fast, but the function call disrupts the instruction pipeline. For this reason the GNU C Library provides optimizations for many of the frequently-used math functions. When GNU CC is used and the user activates the optimizer, several new inline functions and macros are defined. These new functions and macros have the same names as the library functions and so are used instead of the latter. In the case of inline functions the compiler will decide whether it is reasonable to use them, and this decision is usually correct. This means that no calls to the library functions may be necessary, and can increase the speed of generated code significantly. The drawback is that code size will increase, and the increase is not always negligible. There are two kind of inline functions: Those that give the same result as the library functions and others that might not set `errno' and might have a reduced precision and/or argument range in comparison with the library functions. The latter inline functions are only available if the flag `-ffast-math' is given to GNU CC. In cases where the inline functions and macros are not wanted the symbol `__NO_MATH_INLINES' should be defined before any system header is included. This will ensure that only library functions are used. Of course, it can be determined for each file in the project whether giving this option is preferable or not. Not all hardware implements the entire IEEE 754 standard, and even if it does there may be a substantial performance penalty for using some of its features. For example, enabling traps on some processors forces the FPU to run un-pipelined, which can more than double calculation time.  File: libc.info, Node: Arithmetic, Next: Date and Time, Prev: Mathematics, Up: Top Arithmetic Functions ******************** This chapter contains information about functions for doing basic arithmetic operations, such as splitting a float into its integer and fractional parts or retrieving the imaginary part of a complex value. These functions are declared in the header files `math.h' and `complex.h'. * Menu: * Integers:: Basic integer types and concepts * Integer Division:: Integer division with guaranteed rounding. * Floating Point Numbers:: Basic concepts. IEEE 754. * Floating Point Classes:: The five kinds of floating-point number. * Floating Point Errors:: When something goes wrong in a calculation. * Rounding:: Controlling how results are rounded. * Control Functions:: Saving and restoring the FPU's state. * Arithmetic Functions:: Fundamental operations provided by the library. * Complex Numbers:: The types. Writing complex constants. * Operations on Complex:: Projection, conjugation, decomposition. * Parsing of Numbers:: Converting strings to numbers. * System V Number Conversion:: An archaic way to convert numbers to strings.  File: libc.info, Node: Integers, Next: Integer Division, Up: Arithmetic Integers ======== The C language defines several integer data types: integer, short integer, long integer, and character, all in both signed and unsigned varieties. The GNU C compiler extends the language to contain long long integers as well. The C integer types were intended to allow code to be portable among machines with different inherent data sizes (word sizes), so each type may have different ranges on different machines. The problem with this is that a program often needs to be written for a particular range of integers, and sometimes must be written for a particular size of storage, regardless of what machine the program runs on. To address this problem, the GNU C library contains C type definitions you can use to declare integers that meet your exact needs. Because the GNU C library header files are customized to a specific machine, your program source code doesn't have to be. These `typedef's are in `stdint.h'. If you require that an integer be represented in exactly N bits, use one of the following types, with the obvious mapping to bit size and signedness: * int8_t * int16_t * int32_t * int64_t * uint8_t * uint16_t * uint32_t * uint64_t If your C compiler and target machine do not allow integers of a certain size, the corresponding above type does not exist. If you don't need a specific storage size, but want the smallest data structure with _at least_ N bits, use one of these: * int_least8_t * int_least16_t * int_least32_t * int_least64_t * uint_least8_t * uint_least16_t * uint_least32_t * uint_least64_t If you don't need a specific storage size, but want the data structure that allows the fastest access while having at least N bits (and among data structures with the same access speed, the smallest one), use one of these: * int_fast8_t * int_fast16_t * int_fast32_t * int_fast64_t * uint_fast8_t * uint_fast16_t * uint_fast32_t * uint_fast64_t If you want an integer with the widest range possible on the platform on which it is being used, use one of the following. If you use these, you should write code that takes into account the variable size and range of the integer. * intmax_t * uintmax_t The GNU C library also provides macros that tell you the maximum and minimum possible values for each integer data type. The macro names follow these examples: `INT32_MAX', `UINT8_MAX', `INT_FAST32_MIN', `INT_LEAST64_MIN', `UINTMAX_MAX', `INTMAX_MAX', `INTMAX_MIN'. Note that there are no macros for unsigned integer minima. These are always zero. There are similar macros for use with C's built in integer types which should come with your C compiler. These are described in *Note Data Type Measurements::. Don't forget you can use the C `sizeof' function with any of these data types to get the number of bytes of storage each uses.  File: libc.info, Node: Integer Division, Next: Floating Point Numbers, Prev: Integers, Up: Arithmetic Integer Division ================ This section describes functions for performing integer division. These functions are redundant when GNU CC is used, because in GNU C the `/' operator always rounds towards zero. But in other C implementations, `/' may round differently with negative arguments. `div' and `ldiv' are useful because they specify how to round the quotient: towards zero. The remainder has the same sign as the numerator. These functions are specified to return a result R such that the value `R.quot*DENOMINATOR + R.rem' equals NUMERATOR. To use these facilities, you should include the header file `stdlib.h' in your program. - Data Type: div_t This is a structure type used to hold the result returned by the `div' function. It has the following members: `int quot' The quotient from the division. `int rem' The remainder from the division. - Function: div_t div (int NUMERATOR, int DENOMINATOR) This function `div' computes the quotient and remainder from the division of NUMERATOR by DENOMINATOR, returning the result in a structure of type `div_t'. If the result cannot be represented (as in a division by zero), the behavior is undefined. Here is an example, albeit not a very useful one. div_t result; result = div (20, -6); Now `result.quot' is `-3' and `result.rem' is `2'. - Data Type: ldiv_t This is a structure type used to hold the result returned by the `ldiv' function. It has the following members: `long int quot' The quotient from the division. `long int rem' The remainder from the division. (This is identical to `div_t' except that the components are of type `long int' rather than `int'.) - Function: ldiv_t ldiv (long int NUMERATOR, long int DENOMINATOR) The `ldiv' function is similar to `div', except that the arguments are of type `long int' and the result is returned as a structure of type `ldiv_t'. - Data Type: lldiv_t This is a structure type used to hold the result returned by the `lldiv' function. It has the following members: `long long int quot' The quotient from the division. `long long int rem' The remainder from the division. (This is identical to `div_t' except that the components are of type `long long int' rather than `int'.) - Function: lldiv_t lldiv (long long int NUMERATOR, long long int DENOMINATOR) The `lldiv' function is like the `div' function, but the arguments are of type `long long int' and the result is returned as a structure of type `lldiv_t'. The `lldiv' function was added in ISO C99. - Data Type: imaxdiv_t This is a structure type used to hold the result returned by the `imaxdiv' function. It has the following members: `intmax_t quot' The quotient from the division. `intmax_t rem' The remainder from the division. (This is identical to `div_t' except that the components are of type `intmax_t' rather than `int'.) See *Note Integers:: for a description of the `intmax_t' type. - Function: imaxdiv_t imaxdiv (intmax_t NUMERATOR, intmax_t DENOMINATOR) The `imaxdiv' function is like the `div' function, but the arguments are of type `intmax_t' and the result is returned as a structure of type `imaxdiv_t'. See *Note Integers:: for a description of the `intmax_t' type. The `imaxdiv' function was added in ISO C99.  File: libc.info, Node: Floating Point Numbers, Next: Floating Point Classes, Prev: Integer Division, Up: Arithmetic Floating Point Numbers ====================== Most computer hardware has support for two different kinds of numbers: integers (...-3, -2, -1, 0, 1, 2, 3...) and floating-point numbers. Floating-point numbers have three parts: the "mantissa", the "exponent", and the "sign bit". The real number represented by a floating-point value is given by (s ? -1 : 1) * 2^e * M where s is the sign bit, e the exponent, and M the mantissa. *Note Floating Point Concepts::, for details. (It is possible to have a different "base" for the exponent, but all modern hardware uses 2.) Floating-point numbers can represent a finite subset of the real numbers. While this subset is large enough for most purposes, it is important to remember that the only reals that can be represented exactly are rational numbers that have a terminating binary expansion shorter than the width of the mantissa. Even simple fractions such as 1/5 can only be approximated by floating point. Mathematical operations and functions frequently need to produce values that are not representable. Often these values can be approximated closely enough for practical purposes, but sometimes they can't. Historically there was no way to tell when the results of a calculation were inaccurate. Modern computers implement the IEEE 754 standard for numerical computations, which defines a framework for indicating to the program when the results of calculation are not trustworthy. This framework consists of a set of "exceptions" that indicate why a result could not be represented, and the special values "infinity" and "not a number" (NaN).  File: libc.info, Node: Floating Point Classes, Next: Floating Point Errors, Prev: Floating Point Numbers, Up: Arithmetic Floating-Point Number Classification Functions ============================================== ISO C99 defines macros that let you determine what sort of floating-point number a variable holds. - Macro: int fpclassify (_float-type_ X) This is a generic macro which works on all floating-point types and which returns a value of type `int'. The possible values are: `FP_NAN' The floating-point number X is "Not a Number" (*note Infinity and NaN::) `FP_INFINITE' The value of X is either plus or minus infinity (*note Infinity and NaN::) `FP_ZERO' The value of X is zero. In floating-point formats like IEEE 754, where zero can be signed, this value is also returned if X is negative zero. `FP_SUBNORMAL' Numbers whose absolute value is too small to be represented in the normal format are represented in an alternate, "denormalized" format (*note Floating Point Concepts::). This format is less precise but can represent values closer to zero. `fpclassify' returns this value for values of X in this alternate format. `FP_NORMAL' This value is returned for all other values of X. It indicates that there is nothing special about the number. `fpclassify' is most useful if more than one property of a number must be tested. There are more specific macros which only test one property at a time. Generally these macros execute faster than `fpclassify', since there is special hardware support for them. You should therefore use the specific macros whenever possible. - Macro: int isfinite (_float-type_ X) This macro returns a nonzero value if X is finite: not plus or minus infinity, and not NaN. It is equivalent to (fpclassify (x) != FP_NAN && fpclassify (x) != FP_INFINITE) `isfinite' is implemented as a macro which accepts any floating-point type. - Macro: int isnormal (_float-type_ X) This macro returns a nonzero value if X is finite and normalized. It is equivalent to (fpclassify (x) == FP_NORMAL) - Macro: int isnan (_float-type_ X) This macro returns a nonzero value if X is NaN. It is equivalent to (fpclassify (x) == FP_NAN) Another set of floating-point classification functions was provided by BSD. The GNU C library also supports these functions; however, we recommend that you use the ISO C99 macros in new code. Those are standard and will be available more widely. Also, since they are macros, you do not have to worry about the type of their argument. - Function: int isinf (double X) - Function: int isinff (float X) - Function: int isinfl (long double X) This function returns `-1' if X represents negative infinity, `1' if X represents positive infinity, and `0' otherwise. - Function: int isnan (double X) - Function: int isnanf (float X) - Function: int isnanl (long double X) This function returns a nonzero value if X is a "not a number" value, and zero otherwise. *Note:* The `isnan' macro defined by ISO C99 overrides the BSD function. This is normally not a problem, because the two routines behave identically. However, if you really need to get the BSD function for some reason, you can write (isnan) (x) - Function: int finite (double X) - Function: int finitef (float X) - Function: int finitel (long double X) This function returns a nonzero value if X is finite or a "not a number" value, and zero otherwise. *Portability Note:* The functions listed in this section are BSD extensions.  File: libc.info, Node: Floating Point Errors, Next: Rounding, Prev: Floating Point Classes, Up: Arithmetic Errors in Floating-Point Calculations ===================================== * Menu: * FP Exceptions:: IEEE 754 math exceptions and how to detect them. * Infinity and NaN:: Special values returned by calculations. * Status bit operations:: Checking for exceptions after the fact. * Math Error Reporting:: How the math functions report errors.  File: libc.info, Node: FP Exceptions, Next: Infinity and NaN, Up: Floating Point Errors FP Exceptions ------------- The IEEE 754 standard defines five "exceptions" that can occur during a calculation. Each corresponds to a particular sort of error, such as overflow. When exceptions occur (when exceptions are "raised", in the language of the standard), one of two things can happen. By default the exception is simply noted in the floating-point "status word", and the program continues as if nothing had happened. The operation produces a default value, which depends on the exception (see the table below). Your program can check the status word to find out which exceptions happened. Alternatively, you can enable "traps" for exceptions. In that case, when an exception is raised, your program will receive the `SIGFPE' signal. The default action for this signal is to terminate the program. *Note Signal Handling::, for how you can change the effect of the signal. In the System V math library, the user-defined function `matherr' is called when certain exceptions occur inside math library functions. However, the Unix98 standard deprecates this interface. We support it for historical compatibility, but recommend that you do not use it in new programs. The exceptions defined in IEEE 754 are: `Invalid Operation' This exception is raised if the given operands are invalid for the operation to be performed. Examples are (see IEEE 754, section 7): 1. Addition or subtraction: oo - oo. (But oo + oo = oo). 2. Multiplication: 0 * oo. 3. Division: 0/0 or oo/oo. 4. Remainder: x REM y, where y is zero or x is infinite. 5. Square root if the operand is less then zero. More generally, any mathematical function evaluated outside its domain produces this exception. 6. Conversion of a floating-point number to an integer or decimal string, when the number cannot be represented in the target format (due to overflow, infinity, or NaN). 7. Conversion of an unrecognizable input string. 8. Comparison via predicates involving < or >, when one or other of the operands is NaN. You can prevent this exception by using the unordered comparison functions instead; see *Note FP Comparison Functions::. If the exception does not trap, the result of the operation is NaN. `Division by Zero' This exception is raised when a finite nonzero number is divided by zero. If no trap occurs the result is either +oo or -oo, depending on the signs of the operands. `Overflow' This exception is raised whenever the result cannot be represented as a finite value in the precision format of the destination. If no trap occurs the result depends on the sign of the intermediate result and the current rounding mode (IEEE 754, section 7.3): 1. Round to nearest carries all overflows to oo with the sign of the intermediate result. 2. Round toward 0 carries all overflows to the largest representable finite number with the sign of the intermediate result. 3. Round toward -oo carries positive overflows to the largest representable finite number and negative overflows to -oo. 4. Round toward oo carries negative overflows to the most negative representable finite number and positive overflows to oo. Whenever the overflow exception is raised, the inexact exception is also raised. `Underflow' The underflow exception is raised when an intermediate result is too small to be calculated accurately, or if the operation's result rounded to the destination precision is too small to be normalized. When no trap is installed for the underflow exception, underflow is signaled (via the underflow flag) only when both tininess and loss of accuracy have been detected. If no trap handler is installed the operation continues with an imprecise small value, or zero if the destination precision cannot hold the small exact result. `Inexact' This exception is signalled if a rounded result is not exact (such as when calculating the square root of two) or a result overflows without an overflow trap.  File: libc.info, Node: Infinity and NaN, Next: Status bit operations, Prev: FP Exceptions, Up: Floating Point Errors Infinity and NaN ---------------- IEEE 754 floating point numbers can represent positive or negative infinity, and "NaN" (not a number). These three values arise from calculations whose result is undefined or cannot be represented accurately. You can also deliberately set a floating-point variable to any of them, which is sometimes useful. Some examples of calculations that produce infinity or NaN: 1/0 = oo log (0) = -oo sqrt (-1) = NaN When a calculation produces any of these values, an exception also occurs; see *Note FP Exceptions::. The basic operations and math functions all accept infinity and NaN and produce sensible output. Infinities propagate through calculations as one would expect: for example, 2 + oo = oo, 4/oo = 0, atan (oo) = pi/2. NaN, on the other hand, infects any calculation that involves it. Unless the calculation would produce the same result no matter what real value replaced NaN, the result is NaN. In comparison operations, positive infinity is larger than all values except itself and NaN, and negative infinity is smaller than all values except itself and NaN. NaN is "unordered": it is not equal to, greater than, or less than anything, _including itself_. `x == x' is false if the value of `x' is NaN. You can use this to test whether a value is NaN or not, but the recommended way to test for NaN is with the `isnan' function (*note Floating Point Classes::). In addition, `<', `>', `<=', and `>=' will raise an exception when applied to NaNs. `math.h' defines macros that allow you to explicitly set a variable to infinity or NaN. - Macro: float INFINITY An expression representing positive infinity. It is equal to the value produced by mathematical operations like `1.0 / 0.0'. `-INFINITY' represents negative infinity. You can test whether a floating-point value is infinite by comparing it to this macro. However, this is not recommended; you should use the `isfinite' macro instead. *Note Floating Point Classes::. This macro was introduced in the ISO C99 standard. - Macro: float NAN An expression representing a value which is "not a number". This macro is a GNU extension, available only on machines that support the "not a number" value--that is to say, on all machines that support IEEE floating point. You can use `#ifdef NAN' to test whether the machine supports NaN. (Of course, you must arrange for GNU extensions to be visible, such as by defining `_GNU_SOURCE', and then you must include `math.h'.) IEEE 754 also allows for another unusual value: negative zero. This value is produced when you divide a positive number by negative infinity, or when a negative result is smaller than the limits of representation. Negative zero behaves identically to zero in all calculations, unless you explicitly test the sign bit with `signbit' or `copysign'.  File: libc.info, Node: Status bit operations, Next: Math Error Reporting, Prev: Infinity and NaN, Up: Floating Point Errors Examining the FPU status word ----------------------------- ISO C99 defines functions to query and manipulate the floating-point status word. You can use these functions to check for untrapped exceptions when it's convenient, rather than worrying about them in the middle of a calculation. These constants represent the various IEEE 754 exceptions. Not all FPUs report all the different exceptions. Each constant is defined if and only if the FPU you are compiling for supports that exception, so you can test for FPU support with `#ifdef'. They are defined in `fenv.h'. `FE_INEXACT' The inexact exception. `FE_DIVBYZERO' The divide by zero exception. `FE_UNDERFLOW' The underflow exception. `FE_OVERFLOW' The overflow exception. `FE_INVALID' The invalid exception. The macro `FE_ALL_EXCEPT' is the bitwise OR of all exception macros which are supported by the FP implementation. These functions allow you to clear exception flags, test for exceptions, and save and restore the set of exceptions flagged. - Function: int feclearexcept (int EXCEPTS) This function clears all of the supported exception flags indicated by EXCEPTS. The function returns zero in case the operation was successful, a non-zero value otherwise. - Function: int feraiseexcept (int EXCEPTS) This function raises the supported exceptions indicated by EXCEPTS. If more than one exception bit in EXCEPTS is set the order in which the exceptions are raised is undefined except that overflow (`FE_OVERFLOW') or underflow (`FE_UNDERFLOW') are raised before inexact (`FE_INEXACT'). Whether for overflow or underflow the inexact exception is also raised is also implementation dependent. The function returns zero in case the operation was successful, a non-zero value otherwise. - Function: int fetestexcept (int EXCEPTS) Test whether the exception flags indicated by the parameter EXCEPT are currently set. If any of them are, a nonzero value is returned which specifies which exceptions are set. Otherwise the result is zero. To understand these functions, imagine that the status word is an integer variable named STATUS. `feclearexcept' is then equivalent to `status &= ~excepts' and `fetestexcept' is equivalent to `(status & excepts)'. The actual implementation may be very different, of course. Exception flags are only cleared when the program explicitly requests it, by calling `feclearexcept'. If you want to check for exceptions from a set of calculations, you should clear all the flags first. Here is a simple example of the way to use `fetestexcept': { double f; int raised; feclearexcept (FE_ALL_EXCEPT); f = compute (); raised = fetestexcept (FE_OVERFLOW | FE_INVALID); if (raised & FE_OVERFLOW) { /* ... */ } if (raised & FE_INVALID) { /* ... */ } /* ... */ } You cannot explicitly set bits in the status word. You can, however, save the entire status word and restore it later. This is done with the following functions: - Function: int fegetexceptflag (fexcept_t *FLAGP, int EXCEPTS) This function stores in the variable pointed to by FLAGP an implementation-defined value representing the current setting of the exception flags indicated by EXCEPTS. The function returns zero in case the operation was successful, a non-zero value otherwise. - Function: int fesetexceptflag (const fexcept_t *FLAGP, int EXCEPTS) This function restores the flags for the exceptions indicated by EXCEPTS to the values stored in the variable pointed to by FLAGP. The function returns zero in case the operation was successful, a non-zero value otherwise. Note that the value stored in `fexcept_t' bears no resemblance to the bit mask returned by `fetestexcept'. The type may not even be an integer. Do not attempt to modify an `fexcept_t' variable.  File: libc.info, Node: Math Error Reporting, Prev: Status bit operations, Up: Floating Point Errors Error Reporting by Mathematical Functions ----------------------------------------- Many of the math functions are defined only over a subset of the real or complex numbers. Even if they are mathematically defined, their result may be larger or smaller than the range representable by their return type. These are known as "domain errors", "overflows", and "underflows", respectively. Math functions do several things when one of these errors occurs. In this manual we will refer to the complete response as "signalling" a domain error, overflow, or underflow. When a math function suffers a domain error, it raises the invalid exception and returns NaN. It also sets ERRNO to `EDOM'; this is for compatibility with old systems that do not support IEEE 754 exception handling. Likewise, when overflow occurs, math functions raise the overflow exception and return oo or -oo as appropriate. They also set ERRNO to `ERANGE'. When underflow occurs, the underflow exception is raised, and zero (appropriately signed) is returned. ERRNO may be set to `ERANGE', but this is not guaranteed. Some of the math functions are defined mathematically to result in a complex value over parts of their domains. The most familiar example of this is taking the square root of a negative number. The complex math functions, such as `csqrt', will return the appropriate complex value in this case. The real-valued functions, such as `sqrt', will signal a domain error. Some older hardware does not support infinities. On that hardware, overflows instead return a particular very large number (usually the largest representable number). `math.h' defines macros you can use to test for overflow on both old and new hardware. - Macro: double HUGE_VAL - Macro: float HUGE_VALF - Macro: long double HUGE_VALL An expression representing a particular very large number. On machines that use IEEE 754 floating point format, `HUGE_VAL' is infinity. On other machines, it's typically the largest positive number that can be represented. Mathematical functions return the appropriately typed version of `HUGE_VAL' or `-HUGE_VAL' when the result is too large to be represented.  File: libc.info, Node: Rounding, Next: Control Functions, Prev: Floating Point Errors, Up: Arithmetic Rounding Modes ============== Floating-point calculations are carried out internally with extra precision, and then rounded to fit into the destination type. This ensures that results are as precise as the input data. IEEE 754 defines four possible rounding modes: Round to nearest. This is the default mode. It should be used unless there is a specific need for one of the others. In this mode results are rounded to the nearest representable value. If the result is midway between two representable values, the even representable is chosen. "Even" here means the lowest-order bit is zero. This rounding mode prevents statistical bias and guarantees numeric stability: round-off errors in a lengthy calculation will remain smaller than half of `FLT_EPSILON'. Round toward plus Infinity. All results are rounded to the smallest representable value which is greater than the result. Round toward minus Infinity. All results are rounded to the largest representable value which is less than the result. Round toward zero. All results are rounded to the largest representable value whose magnitude is less than that of the result. In other words, if the result is negative it is rounded up; if it is positive, it is rounded down. `fenv.h' defines constants which you can use to refer to the various rounding modes. Each one will be defined if and only if the FPU supports the corresponding rounding mode. `FE_TONEAREST' Round to nearest. `FE_UPWARD' Round toward +oo. `FE_DOWNWARD' Round toward -oo. `FE_TOWARDZERO' Round toward zero. Underflow is an unusual case. Normally, IEEE 754 floating point numbers are always normalized (*note Floating Point Concepts::). Numbers smaller than 2^r (where r is the minimum exponent, `FLT_MIN_RADIX-1' for FLOAT) cannot be represented as normalized numbers. Rounding all such numbers to zero or 2^r would cause some algorithms to fail at 0. Therefore, they are left in denormalized form. That produces loss of precision, since some bits of the mantissa are stolen to indicate the decimal point. If a result is too small to be represented as a denormalized number, it is rounded to zero. However, the sign of the result is preserved; if the calculation was negative, the result is "negative zero". Negative zero can also result from some operations on infinity, such as 4/-oo. Negative zero behaves identically to zero except when the `copysign' or `signbit' functions are used to check the sign bit directly. At any time one of the above four rounding modes is selected. You can find out which one with this function: - Function: int fegetround (void) Returns the currently selected rounding mode, represented by one of the values of the defined rounding mode macros. To change the rounding mode, use this function: - Function: int fesetround (int ROUND) Changes the currently selected rounding mode to ROUND. If ROUND does not correspond to one of the supported rounding modes nothing is changed. `fesetround' returns zero if it changed the rounding mode, a nonzero value if the mode is not supported. You should avoid changing the rounding mode if possible. It can be an expensive operation; also, some hardware requires you to compile your program differently for it to work. The resulting code may run slower. See your compiler documentation for details.  File: libc.info, Node: Control Functions, Next: Arithmetic Functions, Prev: Rounding, Up: Arithmetic Floating-Point Control Functions ================================ IEEE 754 floating-point implementations allow the programmer to decide whether traps will occur for each of the exceptions, by setting bits in the "control word". In C, traps result in the program receiving the `SIGFPE' signal; see *Note Signal Handling::. *Note:* IEEE 754 says that trap handlers are given details of the exceptional situation, and can set the result value. C signals do not provide any mechanism to pass this information back and forth. Trapping exceptions in C is therefore not very useful. It is sometimes necessary to save the state of the floating-point unit while you perform some calculation. The library provides functions which save and restore the exception flags, the set of exceptions that generate traps, and the rounding mode. This information is known as the "floating-point environment". The functions to save and restore the floating-point environment all use a variable of type `fenv_t' to store information. This type is defined in `fenv.h'. Its size and contents are implementation-defined. You should not attempt to manipulate a variable of this type directly. To save the state of the FPU, use one of these functions: - Function: int fegetenv (fenv_t *ENVP) Store the floating-point environment in the variable pointed to by ENVP. The function returns zero in case the operation was successful, a non-zero value otherwise. - Function: int feholdexcept (fenv_t *ENVP) Store the current floating-point environment in the object pointed to by ENVP. Then clear all exception flags, and set the FPU to trap no exceptions. Not all FPUs support trapping no exceptions; if `feholdexcept' cannot set this mode, it returns nonzero value. If it succeeds, it returns zero. The functions which restore the floating-point environment can take these kinds of arguments: * Pointers to `fenv_t' objects, which were initialized previously by a call to `fegetenv' or `feholdexcept'. * The special macro `FE_DFL_ENV' which represents the floating-point environment as it was available at program start. * Implementation defined macros with names starting with `FE_' and having type `fenv_t *'. If possible, the GNU C Library defines a macro `FE_NOMASK_ENV' which represents an environment where every exception raised causes a trap to occur. You can test for this macro using `#ifdef'. It is only defined if `_GNU_SOURCE' is defined. Some platforms might define other predefined environments. To set the floating-point environment, you can use either of these functions: - Function: int fesetenv (const fenv_t *ENVP) Set the floating-point environment to that described by ENVP. The function returns zero in case the operation was successful, a non-zero value otherwise. - Function: int feupdateenv (const fenv_t *ENVP) Like `fesetenv', this function sets the floating-point environment to that described by ENVP. However, if any exceptions were flagged in the status word before `feupdateenv' was called, they remain flagged after the call. In other words, after `feupdateenv' is called, the status word is the bitwise OR of the previous status word and the one saved in ENVP. The function returns zero in case the operation was successful, a non-zero value otherwise. To control for individual exceptions if raising them causes a trap to occur, you can use the following two functions. *Portability Note:* These functions are all GNU extensions. - Function: int feenableexcept (int EXCEPTS) This functions enables traps for each of the exceptions as indicated by the parameter EXCEPT. The individual excepetions are described in *Note Status bit operations::. Only the specified exceptions are enabled, the status of the other exceptions is not changed. The function returns the previous enabled exceptions in case the operation was successful, `-1' otherwise. - Function: int fedisableexcept (int EXCEPTS) This functions disables traps for each of the exceptions as indicated by the parameter EXCEPT. The individual excepetions are described in *Note Status bit operations::. Only the specified exceptions are disabled, the status of the other exceptions is not changed. The function returns the previous enabled exceptions in case the operation was successful, `-1' otherwise. - Function: int fegetexcept (int EXCEPTS) The function returns a bitmask of all currently enabled exceptions. It returns `-1' in case of failure.  File: libc.info, Node: Arithmetic Functions, Next: Complex Numbers, Prev: Control Functions, Up: Arithmetic Arithmetic Functions ==================== The C library provides functions to do basic operations on floating-point numbers. These include absolute value, maximum and minimum, normalization, bit twiddling, rounding, and a few others. * Menu: * Absolute Value:: Absolute values of integers and floats. * Normalization Functions:: Extracting exponents and putting them back. * Rounding Functions:: Rounding floats to integers. * Remainder Functions:: Remainders on division, precisely defined. * FP Bit Twiddling:: Sign bit adjustment. Adding epsilon. * FP Comparison Functions:: Comparisons without risk of exceptions. * Misc FP Arithmetic:: Max, min, positive difference, multiply-add.  File: libc.info, Node: Absolute Value, Next: Normalization Functions, Up: Arithmetic Functions Absolute Value -------------- These functions are provided for obtaining the "absolute value" (or "magnitude") of a number. The absolute value of a real number X is X if X is positive, -X if X is negative. For a complex number Z, whose real part is X and whose imaginary part is Y, the absolute value is `sqrt (X*X + Y*Y)'. Prototypes for `abs', `labs' and `llabs' are in `stdlib.h'; `imaxabs' is declared in `inttypes.h'; `fabs', `fabsf' and `fabsl' are declared in `math.h'. `cabs', `cabsf' and `cabsl' are declared in `complex.h'. - Function: int abs (int NUMBER) - Function: long int labs (long int NUMBER) - Function: long long int llabs (long long int NUMBER) - Function: intmax_t imaxabs (intmax_t NUMBER) These functions return the absolute value of NUMBER. Most computers use a two's complement integer representation, in which the absolute value of `INT_MIN' (the smallest possible `int') cannot be represented; thus, `abs (INT_MIN)' is not defined. `llabs' and `imaxdiv' are new to ISO C99. See *Note Integers:: for a description of the `intmax_t' type. - Function: double fabs (double NUMBER) - Function: float fabsf (float NUMBER) - Function: long double fabsl (long double NUMBER) This function returns the absolute value of the floating-point number NUMBER. - Function: double cabs (complex double Z) - Function: float cabsf (complex float Z) - Function: long double cabsl (complex long double Z) These functions return the absolute value of the complex number Z (*note Complex Numbers::). The absolute value of a complex number is: sqrt (creal (Z) * creal (Z) + cimag (Z) * cimag (Z)) This function should always be used instead of the direct formula because it takes special care to avoid losing precision. It may also take advantage of hardware support for this operation. See `hypot' in *Note Exponents and Logarithms::.  File: libc.info, Node: Normalization Functions, Next: Rounding Functions, Prev: Absolute Value, Up: Arithmetic Functions Normalization Functions ----------------------- The functions described in this section are primarily provided as a way to efficiently perform certain low-level manipulations on floating point numbers that are represented internally using a binary radix; see *Note Floating Point Concepts::. These functions are required to have equivalent behavior even if the representation does not use a radix of 2, but of course they are unlikely to be particularly efficient in those cases. All these functions are declared in `math.h'. - Function: double frexp (double VALUE, int *EXPONENT) - Function: float frexpf (float VALUE, int *EXPONENT) - Function: long double frexpl (long double VALUE, int *EXPONENT) These functions are used to split the number VALUE into a normalized fraction and an exponent. If the argument VALUE is not zero, the return value is VALUE times a power of two, and is always in the range 1/2 (inclusive) to 1 (exclusive). The corresponding exponent is stored in `*EXPONENT'; the return value multiplied by 2 raised to this exponent equals the original number VALUE. For example, `frexp (12.8, &exponent)' returns `0.8' and stores `4' in `exponent'. If VALUE is zero, then the return value is zero and zero is stored in `*EXPONENT'. - Function: double ldexp (double VALUE, int EXPONENT) - Function: float ldexpf (float VALUE, int EXPONENT) - Function: long double ldexpl (long double VALUE, int EXPONENT) These functions return the result of multiplying the floating-point number VALUE by 2 raised to the power EXPONENT. (It can be used to reassemble floating-point numbers that were taken apart by `frexp'.) For example, `ldexp (0.8, 4)' returns `12.8'. The following functions, which come from BSD, provide facilities equivalent to those of `ldexp' and `frexp'. See also the ISO C function `logb' which originally also appeared in BSD. - Function: double scalb (double VALUE, int EXPONENT) - Function: float scalbf (float VALUE, int EXPONENT) - Function: long double scalbl (long double VALUE, int EXPONENT) The `scalb' function is the BSD name for `ldexp'. - Function: long long int scalbn (double X, int n) - Function: long long int scalbnf (float X, int n) - Function: long long int scalbnl (long double X, int n) `scalbn' is identical to `scalb', except that the exponent N is an `int' instead of a floating-point number. - Function: long long int scalbln (double X, long int n) - Function: long long int scalblnf (float X, long int n) - Function: long long int scalblnl (long double X, long int n) `scalbln' is identical to `scalb', except that the exponent N is a `long int' instead of a floating-point number. - Function: long long int significand (double X) - Function: long long int significandf (float X) - Function: long long int significandl (long double X) `significand' returns the mantissa of X scaled to the range [1, 2). It is equivalent to `scalb (X, (double) -ilogb (X))'. This function exists mainly for use in certain standardized tests of IEEE 754 conformance.  File: libc.info, Node: Rounding Functions, Next: Remainder Functions, Prev: Normalization Functions, Up: Arithmetic Functions Rounding Functions ------------------ The functions listed here perform operations such as rounding and truncation of floating-point values. Some of these functions convert floating point numbers to integer values. They are all declared in `math.h'. You can also convert floating-point numbers to integers simply by casting them to `int'. This discards the fractional part, effectively rounding towards zero. However, this only works if the result can actually be represented as an `int'--for very large numbers, this is impossible. The functions listed here return the result as a `double' instead to get around this problem. - Function: double ceil (double X) - Function: float ceilf (float X) - Function: long double ceill (long double X) These functions round X upwards to the nearest integer, returning that value as a `double'. Thus, `ceil (1.5)' is `2.0'. - Function: double floor (double X) - Function: float floorf (float X) - Function: long double floorl (long double X) These functions round X downwards to the nearest integer, returning that value as a `double'. Thus, `floor (1.5)' is `1.0' and `floor (-1.5)' is `-2.0'. - Function: double trunc (double X) - Function: float truncf (float X) - Function: long double truncl (long double X) The `trunc' functions round X towards zero to the nearest integer (returned in floating-point format). Thus, `trunc (1.5)' is `1.0' and `trunc (-1.5)' is `-1.0'. - Function: double rint (double X) - Function: float rintf (float X) - Function: long double rintl (long double X) These functions round X to an integer value according to the current rounding mode. *Note Floating Point Parameters::, for information about the various rounding modes. The default rounding mode is to round to the nearest integer; some machines support other modes, but round-to-nearest is always used unless you explicitly select another. If X was not initially an integer, these functions raise the inexact exception. - Function: double nearbyint (double X) - Function: float nearbyintf (float X) - Function: long double nearbyintl (long double X) These functions return the same value as the `rint' functions, but do not raise the inexact exception if X is not an integer. - Function: double round (double X) - Function: float roundf (float X) - Function: long double roundl (long double X) These functions are similar to `rint', but they round halfway cases away from zero instead of to the nearest even integer. - Function: long int lrint (double X) - Function: long int lrintf (float X) - Function: long int lrintl (long double X) These functions are just like `rint', but they return a `long int' instead of a floating-point number. - Function: long long int llrint (double X) - Function: long long int llrintf (float X) - Function: long long int llrintl (long double X) These functions are just like `rint', but they return a `long long int' instead of a floating-point number. - Function: long int lround (double X) - Function: long int lroundf (float X) - Function: long int lroundl (long double X) These functions are just like `round', but they return a `long int' instead of a floating-point number. - Function: long long int llround (double X) - Function: long long int llroundf (float X) - Function: long long int llroundl (long double X) These functions are just like `round', but they return a `long long int' instead of a floating-point number. - Function: double modf (double VALUE, double *INTEGER-PART) - Function: float modff (float VALUE, float *INTEGER-PART) - Function: long double modfl (long double VALUE, long double *INTEGER-PART) These functions break the argument VALUE into an integer part and a fractional part (between `-1' and `1', exclusive). Their sum equals VALUE. Each of the parts has the same sign as VALUE, and the integer part is always rounded toward zero. `modf' stores the integer part in `*INTEGER-PART', and returns the fractional part. For example, `modf (2.5, &intpart)' returns `0.5' and stores `2.0' into `intpart'.  File: libc.info, Node: Remainder Functions, Next: FP Bit Twiddling, Prev: Rounding Functions, Up: Arithmetic Functions Remainder Functions ------------------- The functions in this section compute the remainder on division of two floating-point numbers. Each is a little different; pick the one that suits your problem. - Function: double fmod (double NUMERATOR, double DENOMINATOR) - Function: float fmodf (float NUMERATOR, float DENOMINATOR) - Function: long double fmodl (long double NUMERATOR, long double DENOMINATOR) These functions compute the remainder from the division of NUMERATOR by DENOMINATOR. Specifically, the return value is `NUMERATOR - N * DENOMINATOR', where N is the quotient of NUMERATOR divided by DENOMINATOR, rounded towards zero to an integer. Thus, `fmod (6.5, 2.3)' returns `1.9', which is `6.5' minus `4.6'. The result has the same sign as the NUMERATOR and has magnitude less than the magnitude of the DENOMINATOR. If DENOMINATOR is zero, `fmod' signals a domain error. - Function: double drem (double NUMERATOR, double DENOMINATOR) - Function: float dremf (float NUMERATOR, float DENOMINATOR) - Function: long double dreml (long double NUMERATOR, long double DENOMINATOR) These functions are like `fmod' except that they rounds the internal quotient N to the nearest integer instead of towards zero to an integer. For example, `drem (6.5, 2.3)' returns `-0.4', which is `6.5' minus `6.9'. The absolute value of the result is less than or equal to half the absolute value of the DENOMINATOR. The difference between `fmod (NUMERATOR, DENOMINATOR)' and `drem (NUMERATOR, DENOMINATOR)' is always either DENOMINATOR, minus DENOMINATOR, or zero. If DENOMINATOR is zero, `drem' signals a domain error. - Function: double remainder (double NUMERATOR, double DENOMINATOR) - Function: float remainderf (float NUMERATOR, float DENOMINATOR) - Function: long double remainderl (long double NUMERATOR, long double DENOMINATOR) This function is another name for `drem'.  File: libc.info, Node: FP Bit Twiddling, Next: FP Comparison Functions, Prev: Remainder Functions, Up: Arithmetic Functions Setting and modifying single bits of FP values ---------------------------------------------- There are some operations that are too complicated or expensive to perform by hand on floating-point numbers. ISO C99 defines functions to do these operations, which mostly involve changing single bits. - Function: double copysign (double X, double Y) - Function: float copysignf (float X, float Y) - Function: long double copysignl (long double X, long double Y) These functions return X but with the sign of Y. They work even if X or Y are NaN or zero. Both of these can carry a sign (although not all implementations support it) and this is one of the few operations that can tell the difference. `copysign' never raises an exception. This function is defined in IEC 559 (and the appendix with recommended functions in IEEE 754/IEEE 854). - Function: int signbit (_float-type_ X) `signbit' is a generic macro which can work on all floating-point types. It returns a nonzero value if the value of X has its sign bit set. This is not the same as `x < 0.0', because IEEE 754 floating point allows zero to be signed. The comparison `-0.0 < 0.0' is false, but `signbit (-0.0)' will return a nonzero value. - Function: double nextafter (double X, double Y) - Function: float nextafterf (float X, float Y) - Function: long double nextafterl (long double X, long double Y) The `nextafter' function returns the next representable neighbor of X in the direction towards Y. The size of the step between X and the result depends on the type of the result. If X = Y the function simply returns Y. If either value is `NaN', `NaN' is returned. Otherwise a value corresponding to the value of the least significant bit in the mantissa is added or subtracted, depending on the direction. `nextafter' will signal overflow or underflow if the result goes outside of the range of normalized numbers. This function is defined in IEC 559 (and the appendix with recommended functions in IEEE 754/IEEE 854). - Function: double nexttoward (double X, long double Y) - Function: float nexttowardf (float X, long double Y) - Function: long double nexttowardl (long double X, long double Y) These functions are identical to the corresponding versions of `nextafter' except that their second argument is a `long double'. - Function: double nan (const char *TAGP) - Function: float nanf (const char *TAGP) - Function: long double nanl (const char *TAGP) The `nan' function returns a representation of NaN, provided that NaN is supported by the target platform. `nan ("N-CHAR-SEQUENCE")' is equivalent to `strtod ("NAN(N-CHAR-SEQUENCE)")'. The argument TAGP is used in an unspecified manner. On IEEE 754 systems, there are many representations of NaN, and TAGP selects one. On other systems it may do nothing.  File: libc.info, Node: FP Comparison Functions, Next: Misc FP Arithmetic, Prev: FP Bit Twiddling, Up: Arithmetic Functions Floating-Point Comparison Functions ----------------------------------- The standard C comparison operators provoke exceptions when one or other of the operands is NaN. For example, int v = a < 1.0; will raise an exception if A is NaN. (This does _not_ happen with `==' and `!='; those merely return false and true, respectively, when NaN is examined.) Frequently this exception is undesirable. ISO C99 therefore defines comparison functions that do not raise exceptions when NaN is examined. All of the functions are implemented as macros which allow their arguments to be of any floating-point type. The macros are guaranteed to evaluate their arguments only once. - Macro: int isgreater (_real-floating_ X, _real-floating_ Y) This macro determines whether the argument X is greater than Y. It is equivalent to `(X) > (Y)', but no exception is raised if X or Y are NaN. - Macro: int isgreaterequal (_real-floating_ X, _real-floating_ Y) This macro determines whether the argument X is greater than or equal to Y. It is equivalent to `(X) >= (Y)', but no exception is raised if X or Y are NaN. - Macro: int isless (_real-floating_ X, _real-floating_ Y) This macro determines whether the argument X is less than Y. It is equivalent to `(X) < (Y)', but no exception is raised if X or Y are NaN. - Macro: int islessequal (_real-floating_ X, _real-floating_ Y) This macro determines whether the argument X is less than or equal to Y. It is equivalent to `(X) <= (Y)', but no exception is raised if X or Y are NaN. - Macro: int islessgreater (_real-floating_ X, _real-floating_ Y) This macro determines whether the argument X is less or greater than Y. It is equivalent to `(X) < (Y) || (X) > (Y)' (although it only evaluates X and Y once), but no exception is raised if X or Y are NaN. This macro is not equivalent to `X != Y', because that expression is true if X or Y are NaN. - Macro: int isunordered (_real-floating_ X, _real-floating_ Y) This macro determines whether its arguments are unordered. In other words, it is true if X or Y are NaN, and false otherwise. Not all machines provide hardware support for these operations. On machines that don't, the macros can be very slow. Therefore, you should not use these functions when NaN is not a concern. *Note:* There are no macros `isequal' or `isunequal'. They are unnecessary, because the `==' and `!=' operators do _not_ throw an exception if one or both of the operands are NaN.  File: libc.info, Node: Misc FP Arithmetic, Prev: FP Comparison Functions, Up: Arithmetic Functions Miscellaneous FP arithmetic functions ------------------------------------- The functions in this section perform miscellaneous but common operations that are awkward to express with C operators. On some processors these functions can use special machine instructions to perform these operations faster than the equivalent C code. - Function: double fmin (double X, double Y) - Function: float fminf (float X, float Y) - Function: long double fminl (long double X, long double Y) The `fmin' function returns the lesser of the two values X and Y. It is similar to the expression ((x) < (y) ? (x) : (y)) except that X and Y are only evaluated once. If an argument is NaN, the other argument is returned. If both arguments are NaN, NaN is returned. - Function: double fmax (double X, double Y) - Function: float fmaxf (float X, float Y) - Function: long double fmaxl (long double X, long double Y) The `fmax' function returns the greater of the two values X and Y. If an argument is NaN, the other argument is returned. If both arguments are NaN, NaN is returned. - Function: double fdim (double X, double Y) - Function: float fdimf (float X, float Y) - Function: long double fdiml (long double X, long double Y) The `fdim' function returns the positive difference between X and Y. The positive difference is X - Y if X is greater than Y, and 0 otherwise. If X, Y, or both are NaN, NaN is returned. - Function: double fma (double X, double Y, double Z) - Function: float fmaf (float X, float Y, float Z) - Function: long double fmal (long double X, long double Y, long double Z) The `fma' function performs floating-point multiply-add. This is the operation (X * Y) + Z, but the intermediate result is not rounded to the destination type. This can sometimes improve the precision of a calculation. This function was introduced because some processors have a special instruction to perform multiply-add. The C compiler cannot use it directly, because the expression `x*y + z' is defined to round the intermediate result. `fma' lets you choose when you want to round only once. On processors which do not implement multiply-add in hardware, `fma' can be very slow since it must avoid intermediate rounding. `math.h' defines the symbols `FP_FAST_FMA', `FP_FAST_FMAF', and `FP_FAST_FMAL' when the corresponding version of `fma' is no slower than the expression `x*y + z'. In the GNU C library, this always means the operation is implemented in hardware.  File: libc.info, Node: Complex Numbers, Next: Operations on Complex, Prev: Arithmetic Functions, Up: Arithmetic Complex Numbers =============== ISO C99 introduces support for complex numbers in C. This is done with a new type qualifier, `complex'. It is a keyword if and only if `complex.h' has been included. There are three complex types, corresponding to the three real types: `float complex', `double complex', and `long double complex'. To construct complex numbers you need a way to indicate the imaginary part of a number. There is no standard notation for an imaginary floating point constant. Instead, `complex.h' defines two macros that can be used to create complex numbers. - Macro: const float complex _Complex_I This macro is a representation of the complex number "0+1i". Multiplying a real floating-point value by `_Complex_I' gives a complex number whose value is purely imaginary. You can use this to construct complex constants: 3.0 + 4.0i = `3.0 + 4.0 * _Complex_I' Note that `_Complex_I * _Complex_I' has the value `-1', but the type of that value is `complex'. `_Complex_I' is a bit of a mouthful. `complex.h' also defines a shorter name for the same constant. - Macro: const float complex I This macro has exactly the same value as `_Complex_I'. Most of the time it is preferable. However, it causes problems if you want to use the identifier `I' for something else. You can safely write #include #undef I if you need `I' for your own purposes. (In that case we recommend you also define some other short name for `_Complex_I', such as `J'.)  File: libc.info, Node: Operations on Complex, Next: Parsing of Numbers, Prev: Complex Numbers, Up: Arithmetic Projections, Conjugates, and Decomposing of Complex Numbers =========================================================== ISO C99 also defines functions that perform basic operations on complex numbers, such as decomposition and conjugation. The prototypes for all these functions are in `complex.h'. All functions are available in three variants, one for each of the three complex types. - Function: double creal (complex double Z) - Function: float crealf (complex float Z) - Function: long double creall (complex long double Z) These functions return the real part of the complex number Z. - Function: double cimag (complex double Z) - Function: float cimagf (complex float Z) - Function: long double cimagl (complex long double Z) These functions return the imaginary part of the complex number Z. - Function: complex double conj (complex double Z) - Function: complex float conjf (complex float Z) - Function: complex long double conjl (complex long double Z) These functions return the conjugate value of the complex number Z. The conjugate of a complex number has the same real part and a negated imaginary part. In other words, `conj(a + bi) = a + -bi'. - Function: double carg (complex double Z) - Function: float cargf (complex float Z) - Function: long double cargl (complex long double Z) These functions return the argument of the complex number Z. The argument of a complex number is the angle in the complex plane between the positive real axis and a line passing through zero and the number. This angle is measured in the usual fashion and ranges from 0 to 2pi. `carg' has a branch cut along the positive real axis. - Function: complex double cproj (complex double Z) - Function: complex float cprojf (complex float Z) - Function: complex long double cprojl (complex long double Z) These functions return the projection of the complex value Z onto the Riemann sphere. Values with a infinite imaginary part are projected to positive infinity on the real axis, even if the real part is NaN. If the real part is infinite, the result is equivalent to INFINITY + I * copysign (0.0, cimag (z))  File: libc.info, Node: Parsing of Numbers, Next: System V Number Conversion, Prev: Operations on Complex, Up: Arithmetic Parsing of Numbers ================== This section describes functions for "reading" integer and floating-point numbers from a string. It may be more convenient in some cases to use `sscanf' or one of the related functions; see *Note Formatted Input::. But often you can make a program more robust by finding the tokens in the string by hand, then converting the numbers one by one. * Menu: * Parsing of Integers:: Functions for conversion of integer values. * Parsing of Floats:: Functions for conversion of floating-point values.  File: libc.info, Node: Parsing of Integers, Next: Parsing of Floats, Up: Parsing of Numbers Parsing of Integers ------------------- The `str' functions are declared in `stdlib.h' and those beginning with `wcs' are declared in `wchar.h'. One might wonder about the use of `restrict' in the prototypes of the functions in this section. It is seemingly useless but the ISO C standard uses it (for the functions defined there) so we have to do it as well. - Function: long int strtol (const char *restrict STRING, char **restrict TAILPTR, int BASE) The `strtol' ("string-to-long") function converts the initial part of STRING to a signed integer, which is returned as a value of type `long int'. This function attempts to decompose STRING as follows: * A (possibly empty) sequence of whitespace characters. Which characters are whitespace is determined by the `isspace' function (*note Classification of Characters::). These are discarded. * An optional plus or minus sign (`+' or `-'). * A nonempty sequence of digits in the radix specified by BASE. If BASE is zero, decimal radix is assumed unless the series of digits begins with `0' (specifying octal radix), or `0x' or `0X' (specifying hexadecimal radix); in other words, the same syntax used for integer constants in C. Otherwise BASE must have a value between `2' and `36'. If BASE is `16', the digits may optionally be preceded by `0x' or `0X'. If base has no legal value the value returned is `0l' and the global variable `errno' is set to `EINVAL'. * Any remaining characters in the string. If TAILPTR is not a null pointer, `strtol' stores a pointer to this tail in `*TAILPTR'. If the string is empty, contains only whitespace, or does not contain an initial substring that has the expected syntax for an integer in the specified BASE, no conversion is performed. In this case, `strtol' returns a value of zero and the value stored in `*TAILPTR' is the value of STRING. In a locale other than the standard `"C"' locale, this function may recognize additional implementation-dependent syntax. If the string has valid syntax for an integer but the value is not representable because of overflow, `strtol' returns either `LONG_MAX' or `LONG_MIN' (*note Range of Type::), as appropriate for the sign of the value. It also sets `errno' to `ERANGE' to indicate there was overflow. You should not check for errors by examining the return value of `strtol', because the string might be a valid representation of `0l', `LONG_MAX', or `LONG_MIN'. Instead, check whether TAILPTR points to what you expect after the number (e.g. `'\0'' if the string should end after the number). You also need to clear ERRNO before the call and check it afterward, in case there was overflow. There is an example at the end of this section. - Function: long int wcstol (const wchar_t *restrict STRING, wchar_t **restrict TAILPTR, int BASE) The `wcstol' function is equivalent to the `strtol' function in nearly all aspects but handles wide character strings. The `wcstol' function was introduced in Amendment 1 of ISO C90. - Function: unsigned long int strtoul (const char *retrict STRING, char **restrict TAILPTR, int BASE) The `strtoul' ("string-to-unsigned-long") function is like `strtol' except it converts to an `unsigned long int' value. The syntax is the same as described above for `strtol'. The value returned on overflow is `ULONG_MAX' (*note Range of Type::). If STRING depicts a negative number, `strtoul' acts the same as STRTOL but casts the result to an unsigned integer. That means for example that `strtoul' on `"-1"' returns `ULONG_MAX' and an input more negative than `LONG_MIN' returns (`ULONG_MAX' + 1) / 2. `strtoul' sets ERRNO to `EINVAL' if BASE is out of range, or `ERANGE' on overflow. - Function: unsigned long int wcstoul (const wchar_t *restrict STRING, wchar_t **restrict TAILPTR, int BASE) The `wcstoul' function is equivalent to the `strtoul' function in nearly all aspects but handles wide character strings. The `wcstoul' function was introduced in Amendment 1 of ISO C90. - Function: long long int strtoll (const char *restrict STRING, char **restrict TAILPTR, int BASE) The `strtoll' function is like `strtol' except that it returns a `long long int' value, and accepts numbers with a correspondingly larger range. If the string has valid syntax for an integer but the value is not representable because of overflow, `strtoll' returns either `LONG_LONG_MAX' or `LONG_LONG_MIN' (*note Range of Type::), as appropriate for the sign of the value. It also sets `errno' to `ERANGE' to indicate there was overflow. The `strtoll' function was introduced in ISO C99. - Function: long long int wcstoll (const wchar_t *restrict STRING, wchar_t **restrict TAILPTR, int BASE) The `wcstoll' function is equivalent to the `strtoll' function in nearly all aspects but handles wide character strings. The `wcstoll' function was introduced in Amendment 1 of ISO C90. - Function: long long int strtoq (const char *restrict STRING, char **restrict TAILPTR, int BASE) `strtoq' ("string-to-quad-word") is the BSD name for `strtoll'. - Function: long long int wcstoq (const wchar_t *restrict STRING, wchar_t **restrict TAILPTR, int BASE) The `wcstoq' function is equivalent to the `strtoq' function in nearly all aspects but handles wide character strings. The `wcstoq' function is a GNU extension. - Function: unsigned long long int strtoull (const char *restrict STRING, char **restrict TAILPTR, int BASE) The `strtoull' function is related to `strtoll' the same way `strtoul' is related to `strtol'. The `strtoull' function was introduced in ISO C99. - Function: unsigned long long int wcstoull (const wchar_t *restrict STRING, wchar_t **restrict TAILPTR, int BASE) The `wcstoull' function is equivalent to the `strtoull' function in nearly all aspects but handles wide character strings. The `wcstoull' function was introduced in Amendment 1 of ISO C90. - Function: unsigned long long int strtouq (const char *restrict STRING, char **restrict TAILPTR, int BASE) `strtouq' is the BSD name for `strtoull'. - Function: unsigned long long int wcstouq (const wchar_t *restrict STRING, wchar_t **restrict TAILPTR, int BASE) The `wcstouq' function is equivalent to the `strtouq' function in nearly all aspects but handles wide character strings. The `wcstoq' function is a GNU extension. - Function: intmax_t strtoimax (const char *restrict STRING, char **restrict TAILPTR, int BASE) The `strtoimax' function is like `strtol' except that it returns a `intmax_t' value, and accepts numbers of a corresponding range. If the string has valid syntax for an integer but the value is not representable because of overflow, `strtoimax' returns either `INTMAX_MAX' or `INTMAX_MIN' (*note Integers::), as appropriate for the sign of the value. It also sets `errno' to `ERANGE' to indicate there was overflow. See *Note Integers:: for a description of the `intmax_t' type. The `strtoimax' function was introduced in ISO C99. - Function: intmax_t wcstoimax (const wchar_t *restrict STRING, wchar_t **restrict TAILPTR, int BASE) The `wcstoimax' function is equivalent to the `strtoimax' function in nearly all aspects but handles wide character strings. The `wcstoimax' function was introduced in ISO C99. - Function: uintmax_t strtoumax (const char *restrict STRING, char **restrict TAILPTR, int BASE) The `strtoumax' function is related to `strtoimax' the same way that `strtoul' is related to `strtol'. See *Note Integers:: for a description of the `intmax_t' type. The `strtoumax' function was introduced in ISO C99. - Function: uintmax_t wcstoumax (const wchar_t *restrict STRING, wchar_t **restrict TAILPTR, int BASE) The `wcstoumax' function is equivalent to the `strtoumax' function in nearly all aspects but handles wide character strings. The `wcstoumax' function was introduced in ISO C99. - Function: long int atol (const char *STRING) This function is similar to the `strtol' function with a BASE argument of `10', except that it need not detect overflow errors. The `atol' function is provided mostly for compatibility with existing code; using `strtol' is more robust. - Function: int atoi (const char *STRING) This function is like `atol', except that it returns an `int'. The `atoi' function is also considered obsolete; use `strtol' instead. - Function: long long int atoll (const char *STRING) This function is similar to `atol', except it returns a `long long int'. The `atoll' function was introduced in ISO C99. It too is obsolete (despite having just been added); use `strtoll' instead. All the functions mentioned in this section so far do not handle alternative representations of characters as described in the locale data. Some locales specify thousands separator and the way they have to be used which can help to make large numbers more readable. To read such numbers one has to use the `scanf' functions with the `'' flag. Here is a function which parses a string as a sequence of integers and returns the sum of them: int sum_ints_from_string (char *string) { int sum = 0; while (1) { char *tail; int next; /* Skip whitespace by hand, to detect the end. */ while (isspace (*string)) string++; if (*string == 0) break; /* There is more nonwhitespace, */ /* so it ought to be another number. */ errno = 0; /* Parse it. */ next = strtol (string, &tail, 0); /* Add it in, if not overflow. */ if (errno) printf ("Overflow\n"); else sum += next; /* Advance past it. */ string = tail; } return sum; }  File: libc.info, Node: Parsing of Floats, Prev: Parsing of Integers, Up: Parsing of Numbers Parsing of Floats ----------------- The `str' functions are declared in `stdlib.h' and those beginning with `wcs' are declared in `wchar.h'. One might wonder about the use of `restrict' in the prototypes of the functions in this section. It is seemingly useless but the ISO C standard uses it (for the functions defined there) so we have to do it as well. - Function: double strtod (const char *restrict STRING, char **restrict TAILPTR) The `strtod' ("string-to-double") function converts the initial part of STRING to a floating-point number, which is returned as a value of type `double'. This function attempts to decompose STRING as follows: * A (possibly empty) sequence of whitespace characters. Which characters are whitespace is determined by the `isspace' function (*note Classification of Characters::). These are discarded. * An optional plus or minus sign (`+' or `-'). * A floating point number in decimal or hexadecimal format. The decimal format is: - A nonempty sequence of digits optionally containing a decimal-point character--normally `.', but it depends on the locale (*note General Numeric::). - An optional exponent part, consisting of a character `e' or `E', an optional sign, and a sequence of digits. The hexadecimal format is as follows: - A 0x or 0X followed by a nonempty sequence of hexadecimal digits optionally containing a decimal-point character--normally `.', but it depends on the locale (*note General Numeric::). - An optional binary-exponent part, consisting of a character `p' or `P', an optional sign, and a sequence of digits. * Any remaining characters in the string. If TAILPTR is not a null pointer, a pointer to this tail of the string is stored in `*TAILPTR'. If the string is empty, contains only whitespace, or does not contain an initial substring that has the expected syntax for a floating-point number, no conversion is performed. In this case, `strtod' returns a value of zero and the value returned in `*TAILPTR' is the value of STRING. In a locale other than the standard `"C"' or `"POSIX"' locales, this function may recognize additional locale-dependent syntax. If the string has valid syntax for a floating-point number but the value is outside the range of a `double', `strtod' will signal overflow or underflow as described in *Note Math Error Reporting::. `strtod' recognizes four special input strings. The strings `"inf"' and `"infinity"' are converted to oo, or to the largest representable value if the floating-point format doesn't support infinities. You can prepend a `"+"' or `"-"' to specify the sign. Case is ignored when scanning these strings. The strings `"nan"' and `"nan(CHARS...)"' are converted to NaN. Again, case is ignored. If CHARS... are provided, they are used in some unspecified fashion to select a particular representation of NaN (there can be several). Since zero is a valid result as well as the value returned on error, you should check for errors in the same way as for `strtol', by examining ERRNO and TAILPTR. - Function: float strtof (const char *STRING, char **TAILPTR) - Function: long double strtold (const char *STRING, char **TAILPTR) These functions are analogous to `strtod', but return `float' and `long double' values respectively. They report errors in the same way as `strtod'. `strtof' can be substantially faster than `strtod', but has less precision; conversely, `strtold' can be much slower but has more precision (on systems where `long double' is a separate type). These functions have been GNU extensions and are new to ISO C99. - Function: double wcstod (const wchar_t *restrict STRING, wchar_t **restrict TAILPTR) - Function: float wcstof (const wchar_t *STRING, wchar_t **TAILPTR) - Function: long double wcstold (const wchar_t *STRING, wchar_t **TAILPTR) The `wcstod', `wcstof', and `wcstol' functions are equivalent in nearly all aspect to the `strtod', `strtof', and `strtold' functions but it handles wide character string. The `wcstod' function was introduced in Amendment 1 of ISO C90. The `wcstof' and `wcstold' functions were introduced in ISO C99. - Function: double atof (const char *STRING) This function is similar to the `strtod' function, except that it need not detect overflow and underflow errors. The `atof' function is provided mostly for compatibility with existing code; using `strtod' is more robust. The GNU C library also provides `_l' versions of these functions, which take an additional argument, the locale to use in conversion. *Note Parsing of Integers::.  File: libc.info, Node: System V Number Conversion, Prev: Parsing of Numbers, Up: Arithmetic Old-fashioned System V number-to-string functions ================================================= The old System V C library provided three functions to convert numbers to strings, with unusual and hard-to-use semantics. The GNU C library also provides these functions and some natural extensions. These functions are only available in glibc and on systems descended from AT&T Unix. Therefore, unless these functions do precisely what you need, it is better to use `sprintf', which is standard. All these functions are defined in `stdlib.h'. - Function: char * ecvt (double VALUE, int NDIGIT, int *DECPT, int *NEG) The function `ecvt' converts the floating-point number VALUE to a string with at most NDIGIT decimal digits. The returned string contains no decimal point or sign. The first digit of the string is non-zero (unless VALUE is actually zero) and the last digit is rounded to nearest. `*DECPT' is set to the index in the string of the first digit after the decimal point. `*NEG' is set to a nonzero value if VALUE is negative, zero otherwise. If NDIGIT decimal digits would exceed the precision of a `double' it is reduced to a system-specific value. The returned string is statically allocated and overwritten by each call to `ecvt'. If VALUE is zero, it is implementation defined whether `*DECPT' is `0' or `1'. For example: `ecvt (12.3, 5, &d, &n)' returns `"12300"' and sets D to `2' and N to `0'. - Function: char * fcvt (double VALUE, int NDIGIT, int *DECPT, int *NEG) The function `fcvt' is like `ecvt', but NDIGIT specifies the number of digits after the decimal point. If NDIGIT is less than zero, VALUE is rounded to the NDIGIT+1'th place to the left of the decimal point. For example, if NDIGIT is `-1', VALUE will be rounded to the nearest 10. If NDIGIT is negative and larger than the number of digits to the left of the decimal point in VALUE, VALUE will be rounded to one significant digit. If NDIGIT decimal digits would exceed the precision of a `double' it is reduced to a system-specific value. The returned string is statically allocated and overwritten by each call to `fcvt'. - Function: char * gcvt (double VALUE, int NDIGIT, char *BUF) `gcvt' is functionally equivalent to `sprintf(buf, "%*g", ndigit, value'. It is provided only for compatibility's sake. It returns BUF. If NDIGIT decimal digits would exceed the precision of a `double' it is reduced to a system-specific value. As extensions, the GNU C library provides versions of these three functions that take `long double' arguments. - Function: char * qecvt (long double VALUE, int NDIGIT, int *DECPT, int *NEG) This function is equivalent to `ecvt' except that it takes a `long double' for the first parameter and that NDIGIT is restricted by the precision of a `long double'. - Function: char * qfcvt (long double VALUE, int NDIGIT, int *DECPT, int *NEG) This function is equivalent to `fcvt' except that it takes a `long double' for the first parameter and that NDIGIT is restricted by the precision of a `long double'. - Function: char * qgcvt (long double VALUE, int NDIGIT, char *BUF) This function is equivalent to `gcvt' except that it takes a `long double' for the first parameter and that NDIGIT is restricted by the precision of a `long double'. The `ecvt' and `fcvt' functions, and their `long double' equivalents, all return a string located in a static buffer which is overwritten by the next call to the function. The GNU C library provides another set of extended functions which write the converted string into a user-supplied buffer. These have the conventional `_r' suffix. `gcvt_r' is not necessary, because `gcvt' already uses a user-supplied buffer. - Function: char * ecvt_r (double VALUE, int NDIGIT, int *DECPT, int *NEG, char *BUF, size_t LEN) The `ecvt_r' function is the same as `ecvt', except that it places its result into the user-specified buffer pointed to by BUF, with length LEN. This function is a GNU extension. - Function: char * fcvt_r (double VALUE, int NDIGIT, int *DECPT, int *NEG, char *BUF, size_t LEN) The `fcvt_r' function is the same as `fcvt', except that it places its result into the user-specified buffer pointed to by BUF, with length LEN. This function is a GNU extension. - Function: char * qecvt_r (long double VALUE, int NDIGIT, int *DECPT, int *NEG, char *BUF, size_t LEN) The `qecvt_r' function is the same as `qecvt', except that it places its result into the user-specified buffer pointed to by BUF, with length LEN. This function is a GNU extension. - Function: char * qfcvt_r (long double VALUE, int NDIGIT, int *DECPT, int *NEG, char *BUF, size_t LEN) The `qfcvt_r' function is the same as `qfcvt', except that it places its result into the user-specified buffer pointed to by BUF, with length LEN. This function is a GNU extension.  File: libc.info, Node: Date and Time, Next: Resource Usage And Limitation, Prev: Arithmetic, Up: Top Date and Time ************* This chapter describes functions for manipulating dates and times, including functions for determining what time it is and conversion between different time representations. * Menu: * Time Basics:: Concepts and definitions. * Elapsed Time:: Data types to represent elapsed times * Processor And CPU Time:: Time a program has spent executing. * Calendar Time:: Manipulation of ``real'' dates and times. * Setting an Alarm:: Sending a signal after a specified time. * Sleeping:: Waiting for a period of time.  File: libc.info, Node: Time Basics, Next: Elapsed Time, Up: Date and Time Time Basics =========== Discussing time in a technical manual can be difficult because the word "time" in English refers to lots of different things. In this manual, we use a rigorous terminology to avoid confusion, and the only thing we use the simple word "time" for is to talk about the abstract concept. A "calendar time" is a point in the time continuum, for example November 4, 1990 at 18:02.5 UTC. Sometimes this is called "absolute time". We don't speak of a "date", because that is inherent in a calendar time. An "interval" is a contiguous part of the time continuum between two calendar times, for example the hour between 9:00 and 10:00 on July 4, 1980. An "elapsed time" is the length of an interval, for example, 35 minutes. People sometimes sloppily use the word "interval" to refer to the elapsed time of some interval. An "amount of time" is a sum of elapsed times, which need not be of any specific intervals. For example, the amount of time it takes to read a book might be 9 hours, independently of when and in how many sittings it is read. A "period" is the elapsed time of an interval between two events, especially when they are part of a sequence of regularly repeating events. "CPU time" is like calendar time, except that it is based on the subset of the time continuum when a particular process is actively using a CPU. CPU time is, therefore, relative to a process. "Processor time" is an amount of time that a CPU is in use. In fact, it's a basic system resource, since there's a limit to how much can exist in any given interval (that limit is the elapsed time of the interval times the number of CPUs in the processor). People often call this CPU time, but we reserve the latter term in this manual for the definition above.  File: libc.info, Node: Elapsed Time, Next: Processor And CPU Time, Prev: Time Basics, Up: Date and Time Elapsed Time ============ One way to represent an elapsed time is with a simple arithmetic data type, as with the following function to compute the elapsed time between two calendar times. This function is declared in `time.h'. - Function: double difftime (time_t TIME1, time_t TIME0) The `difftime' function returns the number of seconds of elapsed time between calendar time TIME1 and calendar time TIME0, as a value of type `double'. The difference ignores leap seconds unless leap second support is enabled. In the GNU system, you can simply subtract `time_t' values. But on other systems, the `time_t' data type might use some other encoding where subtraction doesn't work directly. The GNU C library provides two data types specifically for representing an elapsed time. They are used by various GNU C library functions, and you can use them for your own purposes too. They're exactly the same except that one has a resolution in microseconds, and the other, newer one, is in nanoseconds. - Data Type: struct timeval The `struct timeval' structure represents an elapsed time. It is declared in `sys/time.h' and has the following members: `long int tv_sec' This represents the number of whole seconds of elapsed time. `long int tv_usec' This is the rest of the elapsed time (a fraction of a second), represented as the number of microseconds. It is always less than one million. - Data Type: struct timespec The `struct timespec' structure represents an elapsed time. It is declared in `time.h' and has the following members: `long int tv_sec' This represents the number of whole seconds of elapsed time. `long int tv_nsec' This is the rest of the elapsed time (a fraction of a second), represented as the number of nanoseconds. It is always less than one billion. It is often necessary to subtract two values of type `struct timeval' or `struct timespec'. Here is the best way to do this. It works even on some peculiar operating systems where the `tv_sec' member has an unsigned type. /* Subtract the `struct timeval' values X and Y, storing the result in RESULT. Return 1 if the difference is negative, otherwise 0. */ int timeval_subtract (result, x, y) struct timeval *result, *x, *y; { /* Perform the carry for the later subtraction by updating Y. */ if (x->tv_usec < y->tv_usec) { int nsec = (y->tv_usec - x->tv_usec) / 1000000 + 1; y->tv_usec -= 1000000 * nsec; y->tv_sec += nsec; } if (x->tv_usec - y->tv_usec > 1000000) { int nsec = (x->tv_usec - y->tv_usec) / 1000000; y->tv_usec += 1000000 * nsec; y->tv_sec -= nsec; } /* Compute the time remaining to wait. `tv_usec' is certainly positive. */ result->tv_sec = x->tv_sec - y->tv_sec; result->tv_usec = x->tv_usec - y->tv_usec; /* Return 1 if result is negative. */ return x->tv_sec < y->tv_sec; } Common functions that use `struct timeval' are `gettimeofday' and `settimeofday'. There are no GNU C library functions specifically oriented toward dealing with elapsed times, but the calendar time, processor time, and alarm and sleeping functions have a lot to do with them.  File: libc.info, Node: Processor And CPU Time, Next: Calendar Time, Prev: Elapsed Time, Up: Date and Time Processor And CPU Time ====================== If you're trying to optimize your program or measure its efficiency, it's very useful to know how much processor time it uses. For that, calendar time and elapsed times are useless because a process may spend time waiting for I/O or for other processes to use the CPU. However, you can get the information with the functions in this section. CPU time (*note Time Basics::) is represented by the data type `clock_t', which is a number of "clock ticks". It gives the total amount of time a process has actively used a CPU since some arbitrary event. On the GNU system, that event is the creation of the process. While arbitrary in general, the event is always the same event for any particular process, so you can always measure how much time on the CPU a particular computation takes by examinining the process' CPU time before and after the computation. In the GNU system, `clock_t' is equivalent to `long int' and `CLOCKS_PER_SEC' is an integer value. But in other systems, both `clock_t' and the macro `CLOCKS_PER_SEC' can be either integer or floating-point types. Casting CPU time values to `double', as in the example above, makes sure that operations such as arithmetic and printing work properly and consistently no matter what the underlying representation is. Note that the clock can wrap around. On a 32bit system with `CLOCKS_PER_SEC' set to one million this function will return the same value approximately every 72 minutes. For additional functions to examine a process' use of processor time, and to control it, *Note Resource Usage And Limitation::. * Menu: * CPU Time:: The `clock' function. * Processor Time:: The `times' function.  File: libc.info, Node: CPU Time, Next: Processor Time, Up: Processor And CPU Time CPU Time Inquiry ---------------- To get a process' CPU time, you can use the `clock' function. This facility is declared in the header file `time.h'. In typical usage, you call the `clock' function at the beginning and end of the interval you want to time, subtract the values, and then divide by `CLOCKS_PER_SEC' (the number of clock ticks per second) to get processor time, like this: #include clock_t start, end; double cpu_time_used; start = clock(); ... /* Do the work. */ end = clock(); cpu_time_used = ((double) (end - start)) / CLOCKS_PER_SEC; Do not use a single CPU time as an amount of time; it doesn't work that way. Either do a subtraction as shown above or query processor time directly. *Note Processor Time::. Different computers and operating systems vary wildly in how they keep track of CPU time. It's common for the internal processor clock to have a resolution somewhere between a hundredth and millionth of a second. - Macro: int CLOCKS_PER_SEC The value of this macro is the number of clock ticks per second measured by the `clock' function. POSIX requires that this value be one million independent of the actual resolution. - Macro: int CLK_TCK This is an obsolete name for `CLOCKS_PER_SEC'. - Data Type: clock_t This is the type of the value returned by the `clock' function. Values of type `clock_t' are numbers of clock ticks. - Function: clock_t clock (void) This function returns the calling process' current CPU time. If the CPU time is not available or cannot be represented, `clock' returns the value `(clock_t)(-1)'.  File: libc.info, Node: Processor Time, Prev: CPU Time, Up: Processor And CPU Time Processor Time Inquiry ---------------------- The `times' function returns information about a process' consumption of processor time in a `struct tms' object, in addition to the process' CPU time. *Note Time Basics::. You should include the header file `sys/times.h' to use this facility. - Data Type: struct tms The `tms' structure is used to return information about process times. It contains at least the following members: `clock_t tms_utime' This is the total processor time the calling process has used in executing the instructions of its program. `clock_t tms_stime' This is the processor time the system has used on behalf of the calling process. `clock_t tms_cutime' This is the sum of the `tms_utime' values and the `tms_cutime' values of all terminated child processes of the calling process, whose status has been reported to the parent process by `wait' or `waitpid'; see *Note Process Completion::. In other words, it represents the total processor time used in executing the instructions of all the terminated child processes of the calling process, excluding child processes which have not yet been reported by `wait' or `waitpid'. `clock_t tms_cstime' This is similar to `tms_cutime', but represents the total processor time system has used on behalf of all the terminated child processes of the calling process. All of the times are given in numbers of clock ticks. Unlike CPU time, these are the actual amounts of time; not relative to any event. *Note Creating a Process::. - Function: clock_t times (struct tms *BUFFER) The `times' function stores the processor time information for the calling process in BUFFER. The return value is the calling process' CPU time (the same value you get from `clock()'. `times' returns `(clock_t)(-1)' to indicate failure. *Portability Note:* The `clock' function described in *Note CPU Time:: is specified by the ISO C standard. The `times' function is a feature of POSIX.1. In the GNU system, the CPU time is defined to be equivalent to the sum of the `tms_utime' and `tms_stime' fields returned by `times'.  File: libc.info, Node: Calendar Time, Next: Setting an Alarm, Prev: Processor And CPU Time, Up: Date and Time Calendar Time ============= This section describes facilities for keeping track of calendar time. *Note Time Basics::. The GNU C library represents calendar time three ways: * "Simple time" (the `time_t' data type) is a compact representation, typically giving the number of seconds of elapsed time since some implementation-specific base time. * There is also a "high-resolution time" representation. Like simple time, this represents a calendar time as an elapsed time since a base time, but instead of measuring in whole seconds, it uses a `struct timeval' data type, which includes fractions of a second. Use this time representation instead of simple time when you need greater precision. * "Local time" or "broken-down time" (the `struct tm' data type) represents a calendar time as a set of components specifying the year, month, and so on in the Gregorian calendar, for a specific time zone. This calendar time representation is usually used only to communicate with people. * Menu: * Simple Calendar Time:: Facilities for manipulating calendar time. * High-Resolution Calendar:: A time representation with greater precision. * Broken-down Time:: Facilities for manipulating local time. * High Accuracy Clock:: Maintaining a high accuracy system clock. * Formatting Calendar Time:: Converting times to strings. * Parsing Date and Time:: Convert textual time and date information back into broken-down time values. * TZ Variable:: How users specify the time zone. * Time Zone Functions:: Functions to examine or specify the time zone. * Time Functions Example:: An example program showing use of some of the time functions.  File: libc.info, Node: Simple Calendar Time, Next: High-Resolution Calendar, Up: Calendar Time Simple Calendar Time -------------------- This section describes the `time_t' data type for representing calendar time as simple time, and the functions which operate on simple time objects. These facilities are declared in the header file `time.h'. - Data Type: time_t This is the data type used to represent simple time. Sometimes, it also represents an elapsed time. When interpreted as a calendar time value, it represents the number of seconds elapsed since 00:00:00 on January 1, 1970, Coordinated Universal Time. (This calendar time is sometimes referred to as the "epoch".) POSIX requires that this count not include leap seconds, but on some systems this count includes leap seconds if you set `TZ' to certain values (*note TZ Variable::). Note that a simple time has no concept of local time zone. Calendar Time T is the same instant in time regardless of where on the globe the computer is. In the GNU C library, `time_t' is equivalent to `long int'. In other systems, `time_t' might be either an integer or floating-point type. The function `difftime' tells you the elapsed time between two simple calendar times, which is not always as easy to compute as just subtracting. *Note Elapsed Time::. - Function: time_t time (time_t *RESULT) The `time' function returns the current calendar time as a value of type `time_t'. If the argument RESULT is not a null pointer, the calendar time value is also stored in `*RESULT'. If the current calendar time is not available, the value `(time_t)(-1)' is returned. - Function: int stime (time_t *NEWTIME) `stime' sets the system clock, i.e. it tells the system that the current calendar time is NEWTIME, where `newtime' is interpreted as described in the above definition of `time_t'. `settimeofday' is a newer function which sets the system clock to better than one second precision. `settimeofday' is generally a better choice than `stime'. *Note High-Resolution Calendar::. Only the superuser can set the system clock. If the function succeeds, the return value is zero. Otherwise, it is `-1' and `errno' is set accordingly: `EPERM' The process is not superuser.  File: libc.info, Node: High-Resolution Calendar, Next: Broken-down Time, Prev: Simple Calendar Time, Up: Calendar Time High-Resolution Calendar ------------------------ The `time_t' data type used to represent simple times has a resolution of only one second. Some applications need more precision. So, the GNU C library also contains functions which are capable of representing calendar times to a higher resolution than one second. The functions and the associated data types described in this section are declared in `sys/time.h'. - Data Type: struct timezone The `struct timezone' structure is used to hold minimal information about the local time zone. It has the following members: `int tz_minuteswest' This is the number of minutes west of UTC. `int tz_dsttime' If nonzero, Daylight Saving Time applies during some part of the year. The `struct timezone' type is obsolete and should never be used. Instead, use the facilities described in *Note Time Zone Functions::. - Function: int gettimeofday (struct timeval *TP, struct timezone *TZP) The `gettimeofday' function returns the current calendar time as the elapsed time since the epoch in the `struct timeval' structure indicated by TP. (*note Elapsed Time:: for a description of `struct timespec'). Information about the time zone is returned in the structure pointed at TZP. If the TZP argument is a null pointer, time zone information is ignored. The return value is `0' on success and `-1' on failure. The following `errno' error condition is defined for this function: `ENOSYS' The operating system does not support getting time zone information, and TZP is not a null pointer. The GNU operating system does not support using `struct timezone' to represent time zone information; that is an obsolete feature of 4.3 BSD. Instead, use the facilities described in *Note Time Zone Functions::. - Function: int settimeofday (const struct timeval *TP, const struct timezone *TZP) The `settimeofday' function sets the current calendar time in the system clock according to the arguments. As for `gettimeofday', the calendar time is represented as the elapsed time since the epoch. As for `gettimeofday', time zone information is ignored if TZP is a null pointer. You must be a privileged user in order to use `settimeofday'. Some kernels automatically set the system clock from some source such as a hardware clock when they start up. Others, including Linux, place the system clock in an "invalid" state (in which attempts to read the clock fail). A call of `stime' removes the system clock from an invalid state, and system startup scripts typically run a program that calls `stime'. `settimeofday' causes a sudden jump forwards or backwards, which can cause a variety of problems in a system. Use `adjtime' (below) to make a smooth transition from one time to another by temporarily speeding up or slowing down the clock. With a Linux kernel, `adjtimex' does the same thing and can also make permanent changes to the speed of the system clock so it doesn't need to be corrected as often. The return value is `0' on success and `-1' on failure. The following `errno' error conditions are defined for this function: `EPERM' This process cannot set the clock because it is not privileged. `ENOSYS' The operating system does not support setting time zone information, and TZP is not a null pointer. - Function: int adjtime (const struct timeval *DELTA, struct timeval *OLDDELTA) This function speeds up or slows down the system clock in order to make a gradual adjustment. This ensures that the calendar time reported by the system clock is always monotonically increasing, which might not happen if you simply set the clock. The DELTA argument specifies a relative adjustment to be made to the clock time. If negative, the system clock is slowed down for a while until it has lost this much elapsed time. If positive, the system clock is speeded up for a while. If the OLDDELTA argument is not a null pointer, the `adjtime' function returns information about any previous time adjustment that has not yet completed. This function is typically used to synchronize the clocks of computers in a local network. You must be a privileged user to use it. With a Linux kernel, you can use the `adjtimex' function to permanently change the clock speed. The return value is `0' on success and `-1' on failure. The following `errno' error condition is defined for this function: `EPERM' You do not have privilege to set the time. *Portability Note:* The `gettimeofday', `settimeofday', and `adjtime' functions are derived from BSD. Symbols for the following function are declared in `sys/timex.h'. - Function: int adjtimex (struct timex *TIMEX) `adjtimex' is functionally identical to `ntp_adjtime'. *Note High Accuracy Clock::. This function is present only with a Linux kernel.  File: libc.info, Node: Broken-down Time, Next: High Accuracy Clock, Prev: High-Resolution Calendar, Up: Calendar Time Broken-down Time ---------------- Calendar time is represented by the usual GNU C library functions as an elapsed time since a fixed base calendar time. This is convenient for computation, but has no relation to the way people normally think of calendar time. By contrast, "broken-down time" is a binary representation of calendar time separated into year, month, day, and so on. Broken-down time values are not useful for calculations, but they are useful for printing human readable time information. A broken-down time value is always relative to a choice of time zone, and it also indicates which time zone that is. The symbols in this section are declared in the header file `time.h'. - Data Type: struct tm This is the data type used to represent a broken-down time. The structure contains at least the following members, which can appear in any order. `int tm_sec' This is the number of full seconds since the top of the minute (normally in the range `0' through `59', but the actual upper limit is `60', to allow for leap seconds if leap second support is available). `int tm_min' This is the number of full minutes since the top of the hour (in the range `0' through `59'). `int tm_hour' This is the number of full hours past midnight (in the range `0' through `23'). `int tm_mday' This is the ordinal day of the month (in the range `1' through `31'). Watch out for this one! As the only ordinal number in the structure, it is inconsistent with the rest of the structure. `int tm_mon' This is the number of full calendar months since the beginning of the year (in the range `0' through `11'). Watch out for this one! People usually use ordinal numbers for month-of-year (where January = 1). `int tm_year' This is the number of full calendar years since 1900. `int tm_wday' This is the number of full days since Sunday (in the range `0' through `6'). `int tm_yday' This is the number of full days since the beginning of the year (in the range `0' through `365'). `int tm_isdst' This is a flag that indicates whether Daylight Saving Time is (or was, or will be) in effect at the time described. The value is positive if Daylight Saving Time is in effect, zero if it is not, and negative if the information is not available. `long int tm_gmtoff' This field describes the time zone that was used to compute this broken-down time value, including any adjustment for daylight saving; it is the number of seconds that you must add to UTC to get local time. You can also think of this as the number of seconds east of UTC. For example, for U.S. Eastern Standard Time, the value is `-5*60*60'. The `tm_gmtoff' field is derived from BSD and is a GNU library extension; it is not visible in a strict ISO C environment. `const char *tm_zone' This field is the name for the time zone that was used to compute this broken-down time value. Like `tm_gmtoff', this field is a BSD and GNU extension, and is not visible in a strict ISO C environment. - Function: struct tm * localtime (const time_t *TIME) The `localtime' function converts the simple time pointed to by TIME to broken-down time representation, expressed relative to the user's specified time zone. The return value is a pointer to a static broken-down time structure, which might be overwritten by subsequent calls to `ctime', `gmtime', or `localtime'. (But no other library function overwrites the contents of this object.) The return value is the null pointer if TIME cannot be represented as a broken-down time; typically this is because the year cannot fit into an `int'. Calling `localtime' has one other effect: it sets the variable `tzname' with information about the current time zone. *Note Time Zone Functions::. Using the `localtime' function is a big problem in multi-threaded programs. The result is returned in a static buffer and this is used in all threads. POSIX.1c introduced a variant of this function. - Function: struct tm * localtime_r (const time_t *TIME, struct tm *RESULTP) The `localtime_r' function works just like the `localtime' function. It takes a pointer to a variable containing a simple time and converts it to the broken-down time format. But the result is not placed in a static buffer. Instead it is placed in the object of type `struct tm' to which the parameter RESULTP points. If the conversion is successful the function returns a pointer to the object the result was written into, i.e., it returns RESULTP. - Function: struct tm * gmtime (const time_t *TIME) This function is similar to `localtime', except that the broken-down time is expressed as Coordinated Universal Time (UTC) (formerly called Greenwich Mean Time (GMT)) rather than relative to a local time zone. As for the `localtime' function we have the problem that the result is placed in a static variable. POSIX.1c also provides a replacement for `gmtime'. - Function: struct tm * gmtime_r (const time_t *TIME, struct tm *RESULTP) This function is similar to `localtime_r', except that it converts just like `gmtime' the given time as Coordinated Universal Time. If the conversion is successful the function returns a pointer to the object the result was written into, i.e., it returns RESULTP. - Function: time_t mktime (struct tm *BROKENTIME) The `mktime' function is used to convert a broken-down time structure to a simple time representation. It also "normalizes" the contents of the broken-down time structure, by filling in the day of week and day of year based on the other date and time components. The `mktime' function ignores the specified contents of the `tm_wday' and `tm_yday' members of the broken-down time structure. It uses the values of the other components to determine the calendar time; it's permissible for these components to have unnormalized values outside their normal ranges. The last thing that `mktime' does is adjust the components of the BROKENTIME structure (including the `tm_wday' and `tm_yday'). If the specified broken-down time cannot be represented as a simple time, `mktime' returns a value of `(time_t)(-1)' and does not modify the contents of BROKENTIME. Calling `mktime' also sets the variable `tzname' with information about the current time zone. *Note Time Zone Functions::. - Function: time_t timelocal (struct tm *BROKENTIME) `timelocal' is functionally identical to `mktime', but more mnemonically named. Note that it is the inverse of the `localtime' function. *Portability note:* `mktime' is essentially universally available. `timelocal' is rather rare. - Function: time_t timegm (struct tm *BROKENTIME) `timegm' is functionally identical to `mktime' except it always takes the input values to be Coordinated Universal Time (UTC) regardless of any local time zone setting. Note that `timegm' is the inverse of `gmtime'. *Portability note:* `mktime' is essentially universally available. `timegm' is rather rare. For the most portable conversion from a UTC broken-down time to a simple time, set the `TZ' environment variable to UTC, call `mktime', then set `TZ' back.  File: libc.info, Node: High Accuracy Clock, Next: Formatting Calendar Time, Prev: Broken-down Time, Up: Calendar Time High Accuracy Clock ------------------- The `ntp_gettime' and `ntp_adjtime' functions provide an interface to monitor and manipulate the system clock to maintain high accuracy time. For example, you can fine tune the speed of the clock or synchronize it with another time source. A typical use of these functions is by a server implementing the Network Time Protocol to synchronize the clocks of multiple systems and high precision clocks. These functions are declared in `sys/timex.h'. - Data Type: struct ntptimeval This structure is used for information about the system clock. It contains the following members: `struct timeval time' This is the current calendar time, expressed as the elapsed time since the epoch. The `struct timeval' data type is described in *Note Elapsed Time::. `long int maxerror' This is the maximum error, measured in microseconds. Unless updated via `ntp_adjtime' periodically, this value will reach some platform-specific maximum value. `long int esterror' This is the estimated error, measured in microseconds. This value can be set by `ntp_adjtime' to indicate the estimated offset of the system clock from the true calendar time. - Function: int ntp_gettime (struct ntptimeval *TPTR) The `ntp_gettime' function sets the structure pointed to by TPTR to current values. The elements of the structure afterwards contain the values the timer implementation in the kernel assumes. They might or might not be correct. If they are not a `ntp_adjtime' call is necessary. The return value is `0' on success and other values on failure. The following `errno' error conditions are defined for this function: `TIME_ERROR' The precision clock model is not properly set up at the moment, thus the clock must be considered unsynchronized, and the values should be treated with care. - Data Type: struct timex This structure is used to control and monitor the system clock. It contains the following members: `unsigned int modes' This variable controls whether and which values are set. Several symbolic constants have to be combined with _binary or_ to specify the effective mode. These constants start with `MOD_'. `long int offset' This value indicates the current offset of the system clock from the true calendar time. The value is given in microseconds. If bit `MOD_OFFSET' is set in `modes', the offset (and possibly other dependent values) can be set. The offset's absolute value must not exceed `MAXPHASE'. `long int frequency' This value indicates the difference in frequency between the true calendar time and the system clock. The value is expressed as scaled PPM (parts per million, 0.0001%). The scaling is `1 << SHIFT_USEC'. The value can be set with bit `MOD_FREQUENCY', but the absolute value must not exceed `MAXFREQ'. `long int maxerror' This is the maximum error, measured in microseconds. A new value can be set using bit `MOD_MAXERROR'. Unless updated via `ntp_adjtime' periodically, this value will increase steadily and reach some platform-specific maximum value. `long int esterror' This is the estimated error, measured in microseconds. This value can be set using bit `MOD_ESTERROR'. `int status' This variable reflects the various states of the clock machinery. There are symbolic constants for the significant bits, starting with `STA_'. Some of these flags can be updated using the `MOD_STATUS' bit. `long int constant' This value represents the bandwidth or stiffness of the PLL (phase locked loop) implemented in the kernel. The value can be changed using bit `MOD_TIMECONST'. `long int precision' This value represents the accuracy or the maximum error when reading the system clock. The value is expressed in microseconds. `long int tolerance' This value represents the maximum frequency error of the system clock in scaled PPM. This value is used to increase the `maxerror' every second. `struct timeval time' The current calendar time. `long int tick' The elapsed time between clock ticks in microseconds. A clock tick is a periodic timer interrupt on which the system clock is based. `long int ppsfreq' This is the first of a few optional variables that are present only if the system clock can use a PPS (pulse per second) signal to discipline the system clock. The value is expressed in scaled PPM and it denotes the difference in frequency between the system clock and the PPS signal. `long int jitter' This value expresses a median filtered average of the PPS signal's dispersion in microseconds. `int shift' This value is a binary exponent for the duration of the PPS calibration interval, ranging from `PPS_SHIFT' to `PPS_SHIFTMAX'. `long int stabil' This value represents the median filtered dispersion of the PPS frequency in scaled PPM. `long int jitcnt' This counter represents the number of pulses where the jitter exceeded the allowed maximum `MAXTIME'. `long int calcnt' This counter reflects the number of successful calibration intervals. `long int errcnt' This counter represents the number of calibration errors (caused by large offsets or jitter). `long int stbcnt' This counter denotes the number of of calibrations where the stability exceeded the threshold. - Function: int ntp_adjtime (struct timex *TPTR) The `ntp_adjtime' function sets the structure specified by TPTR to current values. In addition, `ntp_adjtime' updates some settings to match what you pass to it in *TPTR. Use the `modes' element of *TPTR to select what settings to update. You can set `offset', `freq', `maxerror', `esterror', `status', `constant', and `tick'. `modes' = zero means set nothing. Only the superuser can update settings. The return value is `0' on success and other values on failure. The following `errno' error conditions are defined for this function: `TIME_ERROR' The high accuracy clock model is not properly set up at the moment, thus the clock must be considered unsynchronized, and the values should be treated with care. Another reason could be that the specified new values are not allowed. `EPERM' The process specified a settings update, but is not superuser. For more details see RFC1305 (Network Time Protocol, Version 3) and related documents. *Portability note:* Early versions of the GNU C library did not have this function but did have the synonymous `adjtimex'.  File: libc.info, Node: Formatting Calendar Time, Next: Parsing Date and Time, Prev: High Accuracy Clock, Up: Calendar Time Formatting Calendar Time ------------------------ The functions described in this section format calendar time values as strings. These functions are declared in the header file `time.h'. - Function: char * asctime (const struct tm *BROKENTIME) The `asctime' function converts the broken-down time value that BROKENTIME points to into a string in a standard format: "Tue May 21 13:46:22 1991\n" The abbreviations for the days of week are: `Sun', `Mon', `Tue', `Wed', `Thu', `Fri', and `Sat'. The abbreviations for the months are: `Jan', `Feb', `Mar', `Apr', `May', `Jun', `Jul', `Aug', `Sep', `Oct', `Nov', and `Dec'. The return value points to a statically allocated string, which might be overwritten by subsequent calls to `asctime' or `ctime'. (But no other library function overwrites the contents of this string.) - Function: char * asctime_r (const struct tm *BROKENTIME, char *BUFFER) This function is similar to `asctime' but instead of placing the result in a static buffer it writes the string in the buffer pointed to by the parameter BUFFER. This buffer should have room for at least 26 bytes, including the terminating null. If no error occurred the function returns a pointer to the string the result was written into, i.e., it returns BUFFER. Otherwise return `NULL'. - Function: char * ctime (const time_t *TIME) The `ctime' function is similar to `asctime', except that you specify the calendar time argument as a `time_t' simple time value rather than in broken-down local time format. It is equivalent to asctime (localtime (TIME)) `ctime' sets the variable `tzname', because `localtime' does so. *Note Time Zone Functions::. - Function: char * ctime_r (const time_t *TIME, char *BUFFER) This function is similar to `ctime', but places the result in the string pointed to by BUFFER. It is equivalent to (written using gcc extensions, *note Statement Exprs: (gcc)Statement Exprs.): ({ struct tm tm; asctime_r (localtime_r (time, &tm), buf); }) If no error occurred the function returns a pointer to the string the result was written into, i.e., it returns BUFFER. Otherwise return `NULL'. - Function: size_t strftime (char *S, size_t SIZE, const char *TEMPLATE, const struct tm *BROKENTIME) This function is similar to the `sprintf' function (*note Formatted Input::), but the conversion specifications that can appear in the format template TEMPLATE are specialized for printing components of the date and time BROKENTIME according to the locale currently specified for time conversion (*note Locales::). Ordinary characters appearing in the TEMPLATE are copied to the output string S; this can include multibyte character sequences. Conversion specifiers are introduced by a `%' character, followed by an optional flag which can be one of the following. These flags are all GNU extensions. The first three affect only the output of numbers: `_' The number is padded with spaces. `-' The number is not padded at all. `0' The number is padded with zeros even if the format specifies padding with spaces. `^' The output uses uppercase characters, but only if this is possible (*note Case Conversion::). The default action is to pad the number with zeros to keep it a constant width. Numbers that do not have a range indicated below are never padded, since there is no natural width for them. Following the flag an optional specification of the width is possible. This is specified in decimal notation. If the natural size of the output is of the field has less than the specified number of characters, the result is written right adjusted and space padded to the given size. An optional modifier can follow the optional flag and width specification. The modifiers, which were first standardized by POSIX.2-1992 and by ISO C99, are: `E' Use the locale's alternate representation for date and time. This modifier applies to the `%c', `%C', `%x', `%X', `%y' and `%Y' format specifiers. In a Japanese locale, for example, `%Ex' might yield a date format based on the Japanese Emperors' reigns. `O' Use the locale's alternate numeric symbols for numbers. This modifier applies only to numeric format specifiers. If the format supports the modifier but no alternate representation is available, it is ignored. The conversion specifier ends with a format specifier taken from the following list. The whole `%' sequence is replaced in the output string as follows: `%a' The abbreviated weekday name according to the current locale. `%A' The full weekday name according to the current locale. `%b' The abbreviated month name according to the current locale. `%B' The full month name according to the current locale. `%c' The preferred calendar time representation for the current locale. `%C' The century of the year. This is equivalent to the greatest integer not greater than the year divided by 100. This format was first standardized by POSIX.2-1992 and by ISO C99. `%d' The day of the month as a decimal number (range `01' through `31'). `%D' The date using the format `%m/%d/%y'. This format was first standardized by POSIX.2-1992 and by ISO C99. `%e' The day of the month like with `%d', but padded with blank (range ` 1' through `31'). This format was first standardized by POSIX.2-1992 and by ISO C99. `%F' The date using the format `%Y-%m-%d'. This is the form specified in the ISO 8601 standard and is the preferred form for all uses. This format was first standardized by ISO C99 and by POSIX.1-2001. `%g' The year corresponding to the ISO week number, but without the century (range `00' through `99'). This has the same format and value as `%y', except that if the ISO week number (see `%V') belongs to the previous or next year, that year is used instead. This format was first standardized by ISO C99 and by POSIX.1-2001. `%G' The year corresponding to the ISO week number. This has the same format and value as `%Y', except that if the ISO week number (see `%V') belongs to the previous or next year, that year is used instead. This format was first standardized by ISO C99 and by POSIX.1-2001 but was previously available as a GNU extension. `%h' The abbreviated month name according to the current locale. The action is the same as for `%b'. This format was first standardized by POSIX.2-1992 and by ISO C99. `%H' The hour as a decimal number, using a 24-hour clock (range `00' through `23'). `%I' The hour as a decimal number, using a 12-hour clock (range `01' through `12'). `%j' The day of the year as a decimal number (range `001' through `366'). `%k' The hour as a decimal number, using a 24-hour clock like `%H', but padded with blank (range ` 0' through `23'). This format is a GNU extension. `%l' The hour as a decimal number, using a 12-hour clock like `%I', but padded with blank (range ` 1' through `12'). This format is a GNU extension. `%m' The month as a decimal number (range `01' through `12'). `%M' The minute as a decimal number (range `00' through `59'). `%n' A single `\n' (newline) character. This format was first standardized by POSIX.2-1992 and by ISO C99. `%p' Either `AM' or `PM', according to the given time value; or the corresponding strings for the current locale. Noon is treated as `PM' and midnight as `AM'. In most locales `AM'/`PM' format is not supported, in such cases `"%p"' yields an empty string. `%P' Either `am' or `pm', according to the given time value; or the corresponding strings for the current locale, printed in lowercase characters. Noon is treated as `pm' and midnight as `am'. In most locales `AM'/`PM' format is not supported, in such cases `"%P"' yields an empty string. This format is a GNU extension. `%r' The complete calendar time using the AM/PM format of the current locale. This format was first standardized by POSIX.2-1992 and by ISO C99. In the POSIX locale, this format is equivalent to `%I:%M:%S %p'. `%R' The hour and minute in decimal numbers using the format `%H:%M'. This format was first standardized by ISO C99 and by POSIX.1-2001 but was previously available as a GNU extension. `%s' The number of seconds since the epoch, i.e., since 1970-01-01 00:00:00 UTC. Leap seconds are not counted unless leap second support is available. This format is a GNU extension. `%S' The seconds as a decimal number (range `00' through `60'). `%t' A single `\t' (tabulator) character. This format was first standardized by POSIX.2-1992 and by ISO C99. `%T' The time of day using decimal numbers using the format `%H:%M:%S'. This format was first standardized by POSIX.2-1992 and by ISO C99. `%u' The day of the week as a decimal number (range `1' through `7'), Monday being `1'. This format was first standardized by POSIX.2-1992 and by ISO C99. `%U' The week number of the current year as a decimal number (range `00' through `53'), starting with the first Sunday as the first day of the first week. Days preceding the first Sunday in the year are considered to be in week `00'. `%V' The ISO 8601:1988 week number as a decimal number (range `01' through `53'). ISO weeks start with Monday and end with Sunday. Week `01' of a year is the first week which has the majority of its days in that year; this is equivalent to the week containing the year's first Thursday, and it is also equivalent to the week containing January 4. Week `01' of a year can contain days from the previous year. The week before week `01' of a year is the last week (`52' or `53') of the previous year even if it contains days from the new year. This format was first standardized by POSIX.2-1992 and by ISO C99. `%w' The day of the week as a decimal number (range `0' through `6'), Sunday being `0'. `%W' The week number of the current year as a decimal number (range `00' through `53'), starting with the first Monday as the first day of the first week. All days preceding the first Monday in the year are considered to be in week `00'. `%x' The preferred date representation for the current locale. `%X' The preferred time of day representation for the current locale. `%y' The year without a century as a decimal number (range `00' through `99'). This is equivalent to the year modulo 100. `%Y' The year as a decimal number, using the Gregorian calendar. Years before the year `1' are numbered `0', `-1', and so on. `%z' RFC 822/ISO 8601:1988 style numeric time zone (e.g., `-0600' or `+0100'), or nothing if no time zone is determinable. This format was first standardized by ISO C99 and by POSIX.1-2001 but was previously available as a GNU extension. In the POSIX locale, a full RFC 822 timestamp is generated by the format `"%a, %d %b %Y %H:%M:%S %z"' (or the equivalent `"%a, %d %b %Y %T %z"'). `%Z' The time zone abbreviation (empty if the time zone can't be determined). `%%' A literal `%' character. The SIZE parameter can be used to specify the maximum number of characters to be stored in the array S, including the terminating null character. If the formatted time requires more than SIZE characters, `strftime' returns zero and the contents of the array S are undefined. Otherwise the return value indicates the number of characters placed in the array S, not including the terminating null character. _Warning:_ This convention for the return value which is prescribed in ISO C can lead to problems in some situations. For certain format strings and certain locales the output really can be the empty string and this cannot be discovered by testing the return value only. E.g., in most locales the AM/PM time format is not supported (most of the world uses the 24 hour time representation). In such locales `"%p"' will return the empty string, i.e., the return value is zero. To detect situations like this something similar to the following code should be used: buf[0] = '\1'; len = strftime (buf, bufsize, format, tp); if (len == 0 && buf[0] != '\0') { /* Something went wrong in the strftime call. */ ... } If S is a null pointer, `strftime' does not actually write anything, but instead returns the number of characters it would have written. According to POSIX.1 every call to `strftime' implies a call to `tzset'. So the contents of the environment variable `TZ' is examined before any output is produced. For an example of `strftime', see *Note Time Functions Example::. - Function: size_t wcsftime (wchar_t *S, size_t SIZE, const wchar_t *TEMPLATE, const struct tm *BROKENTIME) The `wcsftime' function is equivalent to the `strftime' function with the difference that it operates on wide character strings. The buffer where the result is stored, pointed to by S, must be an array of wide characters. The parameter SIZE which specifies the size of the output buffer gives the number of wide character, not the number of bytes. Also the format string TEMPLATE is a wide character string. Since all characters needed to specify the format string are in the basic character set it is portably possible to write format strings in the C source code using the `L"..."' notation. The parameter BROKENTIME has the same meaning as in the `strftime' call. The `wcsftime' function supports the same flags, modifiers, and format specifiers as the `strftime' function. The return value of `wcsftime' is the number of wide characters stored in `s'. When more characters would have to be written than can be placed in the buffer S the return value is zero, with the same problems indicated in the `strftime' documentation.  File: libc.info, Node: Parsing Date and Time, Next: TZ Variable, Prev: Formatting Calendar Time, Up: Calendar Time Convert textual time and date information back ---------------------------------------------- The ISO C standard does not specify any functions which can convert the output of the `strftime' function back into a binary format. This led to a variety of more-or-less successful implementations with different interfaces over the years. Then the Unix standard was extended by the addition of two functions: `strptime' and `getdate'. Both have strange interfaces but at least they are widely available. * Menu: * Low-Level Time String Parsing:: Interpret string according to given format. * General Time String Parsing:: User-friendly function to parse data and time strings.  File: libc.info, Node: Low-Level Time String Parsing, Next: General Time String Parsing, Up: Parsing Date and Time Interpret string according to given format .......................................... he first function is rather low-level. It is nevertheless frequently used in software since it is better known. Its interface and implementation are heavily influenced by the `getdate' function, which is defined and implemented in terms of calls to `strptime'. - Function: char * strptime (const char *S, const char *FMT, struct tm *TP) The `strptime' function parses the input string S according to the format string FMT and stores its results in the structure TP. The input string could be generated by a `strftime' call or obtained any other way. It does not need to be in a human-recognizable format; e.g. a date passed as `"02:1999:9"' is acceptable, even though it is ambiguous without context. As long as the format string FMT matches the input string the function will succeed. The user has to make sure, though, that the input can be parsed in a unambiguous way. The string `"1999112"' can be parsed using the format `"%Y%m%d"' as 1999-1-12, 1999-11-2, or even 19991-1-2. It is necessary to add appropriate separators to reliably get results. The format string consists of the same components as the format string of the `strftime' function. The only difference is that the flags `_', `-', `0', and `^' are not allowed. Several of the distinct formats of `strftime' do the same work in `strptime' since differences like case of the input do not matter. For reasons of symmetry all formats are supported, though. The modifiers `E' and `O' are also allowed everywhere the `strftime' function allows them. The formats are: `%a' `%A' The weekday name according to the current locale, in abbreviated form or the full name. `%b' `%B' `%h' The month name according to the current locale, in abbreviated form or the full name. `%c' The date and time representation for the current locale. `%Ec' Like `%c' but the locale's alternative date and time format is used. `%C' The century of the year. It makes sense to use this format only if the format string also contains the `%y' format. `%EC' The locale's representation of the period. Unlike `%C' it sometimes makes sense to use this format since some cultures represent years relative to the beginning of eras instead of using the Gregorian years. `%d' `%e' The day of the month as a decimal number (range `1' through `31'). Leading zeroes are permitted but not required. `%Od' `%Oe' Same as `%d' but using the locale's alternative numeric symbols. Leading zeroes are permitted but not required. `%D' Equivalent to `%m/%d/%y'. `%F' Equivalent to `%Y-%m-%d', which is the ISO 8601 date format. This is a GNU extension following an ISO C99 extension to `strftime'. `%g' The year corresponding to the ISO week number, but without the century (range `00' through `99'). _Note:_ Currently, this is not fully implemented. The format is recognized, input is consumed but no field in TM is set. This format is a GNU extension following a GNU extension of `strftime'. `%G' The year corresponding to the ISO week number. _Note:_ Currently, this is not fully implemented. The format is recognized, input is consumed but no field in TM is set. This format is a GNU extension following a GNU extension of `strftime'. `%H' `%k' The hour as a decimal number, using a 24-hour clock (range `00' through `23'). `%k' is a GNU extension following a GNU extension of `strftime'. `%OH' Same as `%H' but using the locale's alternative numeric symbols. `%I' `%l' The hour as a decimal number, using a 12-hour clock (range `01' through `12'). `%l' is a GNU extension following a GNU extension of `strftime'. `%OI' Same as `%I' but using the locale's alternative numeric symbols. `%j' The day of the year as a decimal number (range `1' through `366'). Leading zeroes are permitted but not required. `%m' The month as a decimal number (range `1' through `12'). Leading zeroes are permitted but not required. `%Om' Same as `%m' but using the locale's alternative numeric symbols. `%M' The minute as a decimal number (range `0' through `59'). Leading zeroes are permitted but not required. `%OM' Same as `%M' but using the locale's alternative numeric symbols. `%n' `%t' Matches any white space. `%p' `%P' The locale-dependent equivalent to `AM' or `PM'. This format is not useful unless `%I' or `%l' is also used. Another complication is that the locale might not define these values at all and therefore the conversion fails. `%P' is a GNU extension following a GNU extension to `strftime'. `%r' The complete time using the AM/PM format of the current locale. A complication is that the locale might not define this format at all and therefore the conversion fails. `%R' The hour and minute in decimal numbers using the format `%H:%M'. `%R' is a GNU extension following a GNU extension to `strftime'. `%s' The number of seconds since the epoch, i.e., since 1970-01-01 00:00:00 UTC. Leap seconds are not counted unless leap second support is available. `%s' is a GNU extension following a GNU extension to `strftime'. `%S' The seconds as a decimal number (range `0' through `60'). Leading zeroes are permitted but not required. *Note:* The Unix specification says the upper bound on this value is `61', a result of a decision to allow double leap seconds. You will not see the value `61' because no minute has more than one leap second, but the myth persists. `%OS' Same as `%S' but using the locale's alternative numeric symbols. `%T' Equivalent to the use of `%H:%M:%S' in this place. `%u' The day of the week as a decimal number (range `1' through `7'), Monday being `1'. Leading zeroes are permitted but not required. _Note:_ Currently, this is not fully implemented. The format is recognized, input is consumed but no field in TM is set. `%U' The week number of the current year as a decimal number (range `0' through `53'). Leading zeroes are permitted but not required. `%OU' Same as `%U' but using the locale's alternative numeric symbols. `%V' The ISO 8601:1988 week number as a decimal number (range `1' through `53'). Leading zeroes are permitted but not required. _Note:_ Currently, this is not fully implemented. The format is recognized, input is consumed but no field in TM is set. `%w' The day of the week as a decimal number (range `0' through `6'), Sunday being `0'. Leading zeroes are permitted but not required. _Note:_ Currently, this is not fully implemented. The format is recognized, input is consumed but no field in TM is set. `%Ow' Same as `%w' but using the locale's alternative numeric symbols. `%W' The week number of the current year as a decimal number (range `0' through `53'). Leading zeroes are permitted but not required. _Note:_ Currently, this is not fully implemented. The format is recognized, input is consumed but no field in TM is set. `%OW' Same as `%W' but using the locale's alternative numeric symbols. `%x' The date using the locale's date format. `%Ex' Like `%x' but the locale's alternative data representation is used. `%X' The time using the locale's time format. `%EX' Like `%X' but the locale's alternative time representation is used. `%y' The year without a century as a decimal number (range `0' through `99'). Leading zeroes are permitted but not required. Note that it is questionable to use this format without the `%C' format. The `strptime' function does regard input values in the range 68 to 99 as the years 1969 to 1999 and the values 0 to 68 as the years 2000 to 2068. But maybe this heuristic fails for some input data. Therefore it is best to avoid `%y' completely and use `%Y' instead. `%Ey' The offset from `%EC' in the locale's alternative representation. `%Oy' The offset of the year (from `%C') using the locale's alternative numeric symbols. `%Y' The year as a decimal number, using the Gregorian calendar. `%EY' The full alternative year representation. `%z' The offset from GMT in ISO 8601/RFC822 format. `%Z' The timezone name. _Note:_ Currently, this is not fully implemented. The format is recognized, input is consumed but no field in TM is set. `%%' A literal `%' character. All other characters in the format string must have a matching character in the input string. Exceptions are white spaces in the input string which can match zero or more whitespace characters in the format string. *Portability Note:* The XPG standard advises applications to use at least one whitespace character (as specified by `isspace') or other non-alphanumeric characters between any two conversion specifications. The GNU C Library does not have this limitation but other libraries might have trouble parsing formats like `"%d%m%Y%H%M%S"'. The `strptime' function processes the input string from right to left. Each of the three possible input elements (white space, literal, or format) are handled one after the other. If the input cannot be matched to the format string the function stops. The remainder of the format and input strings are not processed. The function returns a pointer to the first character it was unable to process. If the input string contains more characters than required by the format string the return value points right after the last consumed input character. If the whole input string is consumed the return value points to the `NULL' byte at the end of the string. If an error occurs, i.e. `strptime' fails to match all of the format string, the function returns `NULL'. The specification of the function in the XPG standard is rather vague, leaving out a few important pieces of information. Most importantly, it does not specify what happens to those elements of TM which are not directly initialized by the different formats. The implementations on different Unix systems vary here. The GNU libc implementation does not touch those fields which are not directly initialized. Exceptions are the `tm_wday' and `tm_yday' elements, which are recomputed if any of the year, month, or date elements changed. This has two implications: * Before calling the `strptime' function for a new input string, you should prepare the TM structure you pass. Normally this will mean initializing all values are to zero. Alternatively, you can set all fields to values like `INT_MAX', allowing you to determine which elements were set by the function call. Zero does not work here since it is a valid value for many of the fields. Careful initialization is necessary if you want to find out whether a certain field in TM was initialized by the function call. * You can construct a `struct tm' value with several consecutive `strptime' calls. A useful application of this is e.g. the parsing of two separate strings, one containing date information and the other time information. By parsing one after the other without clearing the structure in-between, you can construct a complete broken-down time. The following example shows a function which parses a string which is contains the date information in either US style or ISO 8601 form: const char * parse_date (const char *input, struct tm *tm) { const char *cp; /* First clear the result structure. */ memset (tm, '\0', sizeof (*tm)); /* Try the ISO format first. */ cp = strptime (input, "%F", tm); if (cp == NULL) { /* Does not match. Try the US form. */ cp = strptime (input, "%D", tm); } return cp; }  File: libc.info, Node: General Time String Parsing, Prev: Low-Level Time String Parsing, Up: Parsing Date and Time A More User-friendly Way to Parse Times and Dates ................................................. The Unix standard defines another function for parsing date strings. The interface is weird, but if the function happens to suit your application it is just fine. It is problematic to use this function in multi-threaded programs or libraries, since it returns a pointer to a static variable, and uses a global variable and global state (an environment variable). - Variable: getdate_err This variable of type `int' contains the error code of the last unsuccessful call to `getdate'. Defined values are: 1 The environment variable `DATEMSK' is not defined or null. 2 The template file denoted by the `DATEMSK' environment variable cannot be opened. 3 Information about the template file cannot retrieved. 4 The template file is not a regular file. 5 An I/O error occurred while reading the template file. 6 Not enough memory available to execute the function. 7 The template file contains no matching template. 8 The input date is invalid, but would match a template otherwise. This includes dates like February 31st, and dates which cannot be represented in a `time_t' variable. - Function: struct tm * getdate (const char *STRING) The interface to `getdate' is the simplest possible for a function to parse a string and return the value. STRING is the input string and the result is returned in a statically-allocated variable. The details about how the string is processed are hidden from the user. In fact, they can be outside the control of the program. Which formats are recognized is controlled by the file named by the environment variable `DATEMSK'. This file should contain lines of valid format strings which could be passed to `strptime'. The `getdate' function reads these format strings one after the other and tries to match the input string. The first line which completely matches the input string is used. Elements not initialized through the format string retain the values present at the time of the `getdate' function call. The formats recognized by `getdate' are the same as for `strptime'. See above for an explanation. There are only a few extensions to the `strptime' behavior: * If the `%Z' format is given the broken-down time is based on the current time of the timezone matched, not of the current timezone of the runtime environment. _Note_: This is not implemented (currently). The problem is that timezone names are not unique. If a fixed timezone is assumed for a given string (say `EST' meaning US East Coast time), then uses for countries other than the USA will fail. So far we have found no good solution to this. * If only the weekday is specified the selected day depends on the current date. If the current weekday is greater or equal to the `tm_wday' value the current week's day is chosen, otherwise the day next week is chosen. * A similar heuristic is used when only the month is given and not the year. If the month is greater than or equal to the current month, then the current year is used. Otherwise it wraps to next year. The first day of the month is assumed if one is not explicitly specified. * The current hour, minute, and second are used if the appropriate value is not set through the format. * If no date is given tomorrow's date is used if the time is smaller than the current time. Otherwise today's date is taken. It should be noted that the format in the template file need not only contain format elements. The following is a list of possible format strings (taken from the Unix standard): %m %A %B %d, %Y %H:%M:%S %A %B %m/%d/%y %I %p %d,%m,%Y %H:%M at %A the %dst of %B in %Y run job at %I %p,%B %dnd %A den %d. %B %Y %H.%M Uhr As you can see, the template list can contain very specific strings like `run job at %I %p,%B %dnd'. Using the above list of templates and assuming the current time is Mon Sep 22 12:19:47 EDT 1986 we can obtain the following results for the given input. Input Match Result Mon %a Mon Sep 22 12:19:47 EDT 1986 Sun %a Sun Sep 28 12:19:47 EDT 1986 Fri %a Fri Sep 26 12:19:47 EDT 1986 September %B Mon Sep 1 12:19:47 EDT 1986 January %B Thu Jan 1 12:19:47 EST 1987 December %B Mon Dec 1 12:19:47 EST 1986 Sep Mon %b %a Mon Sep 1 12:19:47 EDT 1986 Jan Fri %b %a Fri Jan 2 12:19:47 EST 1987 Dec Mon %b %a Mon Dec 1 12:19:47 EST 1986 Jan Wed 1989 %b %a %Y Wed Jan 4 12:19:47 EST 1989 Fri 9 %a %H Fri Sep 26 09:00:00 EDT 1986 Feb 10:30 %b %H:%S Sun Feb 1 10:00:30 EST 1987 10:30 %H:%M Tue Sep 23 10:30:00 EDT 1986 13:30 %H:%M Mon Sep 22 13:30:00 EDT 1986 The return value of the function is a pointer to a static variable of type `struct tm', or a null pointer if an error occurred. The result is only valid until the next `getdate' call, making this function unusable in multi-threaded applications. The `errno' variable is _not_ changed. Error conditions are stored in the global variable `getdate_err'. See the description above for a list of the possible error values. _Warning:_ The `getdate' function should _never_ be used in SUID-programs. The reason is obvious: using the `DATEMSK' environment variable you can get the function to open any arbitrary file and chances are high that with some bogus input (such as a binary file) the program will crash. - Function: int getdate_r (const char *STRING, struct tm *TP) The `getdate_r' function is the reentrant counterpart of `getdate'. It does not use the global variable `getdate_err' to signal an error, but instead returns an error code. The same error codes as described in the `getdate_err' documentation above are used, with 0 meaning success. Moreover, `getdate_r' stores the broken-down time in the variable of type `struct tm' pointed to by the second argument, rather than in a static variable. This function is not defined in the Unix standard. Nevertheless it is available on some other Unix systems as well. The warning against using `getdate' in SUID-programs applies to `getdate_r' as well.  File: libc.info, Node: TZ Variable, Next: Time Zone Functions, Prev: Parsing Date and Time, Up: Calendar Time Specifying the Time Zone with `TZ' ---------------------------------- In POSIX systems, a user can specify the time zone by means of the `TZ' environment variable. For information about how to set environment variables, see *Note Environment Variables::. The functions for accessing the time zone are declared in `time.h'. You should not normally need to set `TZ'. If the system is configured properly, the default time zone will be correct. You might set `TZ' if you are using a computer over a network from a different time zone, and would like times reported to you in the time zone local to you, rather than what is local to the computer. In POSIX.1 systems the value of the `TZ' variable can be in one of three formats. With the GNU C library, the most common format is the last one, which can specify a selection from a large database of time zone information for many regions of the world. The first two formats are used to describe the time zone information directly, which is both more cumbersome and less precise. But the POSIX.1 standard only specifies the details of the first two formats, so it is good to be familiar with them in case you come across a POSIX.1 system that doesn't support a time zone information database. The first format is used when there is no Daylight Saving Time (or summer time) in the local time zone: STD OFFSET The STD string specifies the name of the time zone. It must be three or more characters long and must not contain a leading colon, embedded digits, commas, nor plus and minus signs. There is no space character separating the time zone name from the OFFSET, so these restrictions are necessary to parse the specification correctly. The OFFSET specifies the time value you must add to the local time to get a Coordinated Universal Time value. It has syntax like [`+'|`-']HH[`:'MM[`:'SS]]. This is positive if the local time zone is west of the Prime Meridian and negative if it is east. The hour must be between `0' and `23', and the minute and seconds between `0' and `59'. For example, here is how we would specify Eastern Standard Time, but without any Daylight Saving Time alternative: EST+5 The second format is used when there is Daylight Saving Time: STD OFFSET DST [OFFSET]`,'START[`/'TIME]`,'END[`/'TIME] The initial STD and OFFSET specify the standard time zone, as described above. The DST string and OFFSET specify the name and offset for the corresponding Daylight Saving Time zone; if the OFFSET is omitted, it defaults to one hour ahead of standard time. The remainder of the specification describes when Daylight Saving Time is in effect. The START field is when Daylight Saving Time goes into effect and the END field is when the change is made back to standard time. The following formats are recognized for these fields: `JN' This specifies the Julian day, with N between `1' and `365'. February 29 is never counted, even in leap years. `N' This specifies the Julian day, with N between `0' and `365'. February 29 is counted in leap years. `MM.W.D' This specifies day D of week W of month M. The day D must be between `0' (Sunday) and `6'. The week W must be between `1' and `5'; week `1' is the first week in which day D occurs, and week `5' specifies the _last_ D day in the month. The month M should be between `1' and `12'. The TIME fields specify when, in the local time currently in effect, the change to the other time occurs. If omitted, the default is `02:00:00'. For example, here is how you would specify the Eastern time zone in the United States, including the appropriate Daylight Saving Time and its dates of applicability. The normal offset from UTC is 5 hours; since this is west of the prime meridian, the sign is positive. Summer time begins on the first Sunday in April at 2:00am, and ends on the last Sunday in October at 2:00am. EST+5EDT,M4.1.0/2,M10.5.0/2 The schedule of Daylight Saving Time in any particular jurisdiction has changed over the years. To be strictly correct, the conversion of dates and times in the past should be based on the schedule that was in effect then. However, this format has no facilities to let you specify how the schedule has changed from year to year. The most you can do is specify one particular schedule--usually the present day schedule--and this is used to convert any date, no matter when. For precise time zone specifications, it is best to use the time zone information database (see below). The third format looks like this: :CHARACTERS Each operating system interprets this format differently; in the GNU C library, CHARACTERS is the name of a file which describes the time zone. If the `TZ' environment variable does not have a value, the operation chooses a time zone by default. In the GNU C library, the default time zone is like the specification `TZ=:/etc/localtime' (or `TZ=:/usr/local/etc/localtime', depending on how GNU C library was configured; *note Installation::). Other C libraries use their own rule for choosing the default time zone, so there is little we can say about them. If CHARACTERS begins with a slash, it is an absolute file name; otherwise the library looks for the file `/share/lib/zoneinfo/CHARACTERS'. The `zoneinfo' directory contains data files describing local time zones in many different parts of the world. The names represent major cities, with subdirectories for geographical areas; for example, `America/New_York', `Europe/London', `Asia/Hong_Kong'. These data files are installed by the system administrator, who also sets `/etc/localtime' to point to the data file for the local time zone. The GNU C library comes with a large database of time zone information for most regions of the world, which is maintained by a community of volunteers and put in the public domain.  File: libc.info, Node: Time Zone Functions, Next: Time Functions Example, Prev: TZ Variable, Up: Calendar Time Functions and Variables for Time Zones -------------------------------------- - Variable: char * tzname [2] The array `tzname' contains two strings, which are the standard names of the pair of time zones (standard and Daylight Saving) that the user has selected. `tzname[0]' is the name of the standard time zone (for example, `"EST"'), and `tzname[1]' is the name for the time zone when Daylight Saving Time is in use (for example, `"EDT"'). These correspond to the STD and DST strings (respectively) from the `TZ' environment variable. If Daylight Saving Time is never used, `tzname[1]' is the empty string. The `tzname' array is initialized from the `TZ' environment variable whenever `tzset', `ctime', `strftime', `mktime', or `localtime' is called. If multiple abbreviations have been used (e.g. `"EWT"' and `"EDT"' for U.S. Eastern War Time and Eastern Daylight Time), the array contains the most recent abbreviation. The `tzname' array is required for POSIX.1 compatibility, but in GNU programs it is better to use the `tm_zone' member of the broken-down time structure, since `tm_zone' reports the correct abbreviation even when it is not the latest one. Though the strings are declared as `char *' the user must refrain from modifying these strings. Modifying the strings will almost certainly lead to trouble. - Function: void tzset (void) The `tzset' function initializes the `tzname' variable from the value of the `TZ' environment variable. It is not usually necessary for your program to call this function, because it is called automatically when you use the other time conversion functions that depend on the time zone. The following variables are defined for compatibility with System V Unix. Like `tzname', these variables are set by calling `tzset' or the other time conversion functions. - Variable: long int timezone This contains the difference between UTC and the latest local standard time, in seconds west of UTC. For example, in the U.S. Eastern time zone, the value is `5*60*60'. Unlike the `tm_gmtoff' member of the broken-down time structure, this value is not adjusted for daylight saving, and its sign is reversed. In GNU programs it is better to use `tm_gmtoff', since it contains the correct offset even when it is not the latest one. - Variable: int daylight This variable has a nonzero value if Daylight Saving Time rules apply. A nonzero value does not necessarily mean that Daylight Saving Time is now in effect; it means only that Daylight Saving Time is sometimes in effect.  File: libc.info, Node: Time Functions Example, Prev: Time Zone Functions, Up: Calendar Time Time Functions Example ---------------------- Here is an example program showing the use of some of the calendar time functions. #include #include #define SIZE 256 int main (void) { char buffer[SIZE]; time_t curtime; struct tm *loctime; /* Get the current time. */ curtime = time (NULL); /* Convert it to local time representation. */ loctime = localtime (&curtime); /* Print out the date and time in the standard format. */ fputs (asctime (loctime), stdout); /* Print it out in a nice format. */ strftime (buffer, SIZE, "Today is %A, %B %d.\n", loctime); fputs (buffer, stdout); strftime (buffer, SIZE, "The time is %I:%M %p.\n", loctime); fputs (buffer, stdout); return 0; } It produces output like this: Wed Jul 31 13:02:36 1991 Today is Wednesday, July 31. The time is 01:02 PM.  File: libc.info, Node: Setting an Alarm, Next: Sleeping, Prev: Calendar Time, Up: Date and Time Setting an Alarm ================ The `alarm' and `setitimer' functions provide a mechanism for a process to interrupt itself in the future. They do this by setting a timer; when the timer expires, the process receives a signal. Each process has three independent interval timers available: * A real-time timer that counts elapsed time. This timer sends a `SIGALRM' signal to the process when it expires. * A virtual timer that counts processor time used by the process. This timer sends a `SIGVTALRM' signal to the process when it expires. * A profiling timer that counts both processor time used by the process, and processor time spent in system calls on behalf of the process. This timer sends a `SIGPROF' signal to the process when it expires. This timer is useful for profiling in interpreters. The interval timer mechanism does not have the fine granularity necessary for profiling native code. You can only have one timer of each kind set at any given time. If you set a timer that has not yet expired, that timer is simply reset to the new value. You should establish a handler for the appropriate alarm signal using `signal' or `sigaction' before issuing a call to `setitimer' or `alarm'. Otherwise, an unusual chain of events could cause the timer to expire before your program establishes the handler. In this case it would be terminated, since termination is the default action for the alarm signals. *Note Signal Handling::. To be able to use the alarm function to interrupt a system call which might block otherwise indefinitely it is important to _not_ set the `SA_RESTART' flag when registering the signal handler using `sigaction'. When not using `sigaction' things get even uglier: the `signal' function has to fixed semantics with respect to restarts. The BSD semantics for this function is to set the flag. Therefore, if `sigaction' for whatever reason cannot be used, it is necessary to use `sysv_signal' and not `signal'. The `setitimer' function is the primary means for setting an alarm. This facility is declared in the header file `sys/time.h'. The `alarm' function, declared in `unistd.h', provides a somewhat simpler interface for setting the real-time timer. - Data Type: struct itimerval This structure is used to specify when a timer should expire. It contains the following members: `struct timeval it_interval' This is the period between successive timer interrupts. If zero, the alarm will only be sent once. `struct timeval it_value' This is the period between now and the first timer interrupt. If zero, the alarm is disabled. The `struct timeval' data type is described in *Note Elapsed Time::. - Function: int setitimer (int WHICH, struct itimerval *NEW, struct itimerval *OLD) The `setitimer' function sets the timer specified by WHICH according to NEW. The WHICH argument can have a value of `ITIMER_REAL', `ITIMER_VIRTUAL', or `ITIMER_PROF'. If OLD is not a null pointer, `setitimer' returns information about any previous unexpired timer of the same kind in the structure it points to. The return value is `0' on success and `-1' on failure. The following `errno' error conditions are defined for this function: `EINVAL' The timer period is too large. - Function: int getitimer (int WHICH, struct itimerval *OLD) The `getitimer' function stores information about the timer specified by WHICH in the structure pointed at by OLD. The return value and error conditions are the same as for `setitimer'. `ITIMER_REAL' This constant can be used as the WHICH argument to the `setitimer' and `getitimer' functions to specify the real-time timer. `ITIMER_VIRTUAL' This constant can be used as the WHICH argument to the `setitimer' and `getitimer' functions to specify the virtual timer. `ITIMER_PROF' This constant can be used as the WHICH argument to the `setitimer' and `getitimer' functions to specify the profiling timer. - Function: unsigned int alarm (unsigned int SECONDS) The `alarm' function sets the real-time timer to expire in SECONDS seconds. If you want to cancel any existing alarm, you can do this by calling `alarm' with a SECONDS argument of zero. The return value indicates how many seconds remain before the previous alarm would have been sent. If there is no previous alarm, `alarm' returns zero. The `alarm' function could be defined in terms of `setitimer' like this: unsigned int alarm (unsigned int seconds) { struct itimerval old, new; new.it_interval.tv_usec = 0; new.it_interval.tv_sec = 0; new.it_value.tv_usec = 0; new.it_value.tv_sec = (long int) seconds; if (setitimer (ITIMER_REAL, &new, &old) < 0) return 0; else return old.it_value.tv_sec; } There is an example showing the use of the `alarm' function in *Note Handler Returns::. If you simply want your process to wait for a given number of seconds, you should use the `sleep' function. *Note Sleeping::. You shouldn't count on the signal arriving precisely when the timer expires. In a multiprocessing environment there is typically some amount of delay involved. *Portability Note:* The `setitimer' and `getitimer' functions are derived from BSD Unix, while the `alarm' function is specified by the POSIX.1 standard. `setitimer' is more powerful than `alarm', but `alarm' is more widely used.  File: libc.info, Node: Sleeping, Prev: Setting an Alarm, Up: Date and Time Sleeping ======== The function `sleep' gives a simple way to make the program wait for a short interval. If your program doesn't use signals (except to terminate), then you can expect `sleep' to wait reliably throughout the specified interval. Otherwise, `sleep' can return sooner if a signal arrives; if you want to wait for a given interval regardless of signals, use `select' (*note Waiting for I/O::) and don't specify any descriptors to wait for. - Function: unsigned int sleep (unsigned int SECONDS) The `sleep' function waits for SECONDS or until a signal is delivered, whichever happens first. If `sleep' function returns because the requested interval is over, it returns a value of zero. If it returns because of delivery of a signal, its return value is the remaining time in the sleep interval. The `sleep' function is declared in `unistd.h'. Resist the temptation to implement a sleep for a fixed amount of time by using the return value of `sleep', when nonzero, to call `sleep' again. This will work with a certain amount of accuracy as long as signals arrive infrequently. But each signal can cause the eventual wakeup time to be off by an additional second or so. Suppose a few signals happen to arrive in rapid succession by bad luck--there is no limit on how much this could shorten or lengthen the wait. Instead, compute the calendar time at which the program should stop waiting, and keep trying to wait until that calendar time. This won't be off by more than a second. With just a little more work, you can use `select' and make the waiting period quite accurate. (Of course, heavy system load can cause additional unavoidable delays--unless the machine is dedicated to one application, there is no way you can avoid this.) On some systems, `sleep' can do strange things if your program uses `SIGALRM' explicitly. Even if `SIGALRM' signals are being ignored or blocked when `sleep' is called, `sleep' might return prematurely on delivery of a `SIGALRM' signal. If you have established a handler for `SIGALRM' signals and a `SIGALRM' signal is delivered while the process is sleeping, the action taken might be just to cause `sleep' to return instead of invoking your handler. And, if `sleep' is interrupted by delivery of a signal whose handler requests an alarm or alters the handling of `SIGALRM', this handler and `sleep' will interfere. On the GNU system, it is safe to use `sleep' and `SIGALRM' in the same program, because `sleep' does not work by means of `SIGALRM'. - Function: int nanosleep (const struct timespec *REQUESTED_TIME, struct timespec *REMAINING) If resolution to seconds is not enough the `nanosleep' function can be used. As the name suggests the sleep interval can be specified in nanoseconds. The actual elapsed time of the sleep interval might be longer since the system rounds the elapsed time you request up to the next integer multiple of the actual resolution the system can deliver. *`requested_time' is the elapsed time of the interval you want to sleep. The function returns as *`remaining' the elapsed time left in the interval for which you requested to sleep. If the interval completed without getting interrupted by a signal, this is zero. `struct timespec' is described in *Note Elapsed Time::. If the function returns because the interval is over the return value is zero. If the function returns -1 the global variable ERRNO is set to the following values: `EINTR' The call was interrupted because a signal was delivered to the thread. If the REMAINING parameter is not the null pointer the structure pointed to by REMAINING is updated to contain the remaining elapsed time. `EINVAL' The nanosecond value in the REQUESTED_TIME parameter contains an illegal value. Either the value is negative or greater than or equal to 1000 million. This function is a cancellation point in multi-threaded programs. This is a problem if the thread allocates some resources (like memory, file descriptors, semaphores or whatever) at the time `nanosleep' is called. If the thread gets canceled these resources stay allocated until the program ends. To avoid this calls to `nanosleep' should be protected using cancellation handlers. The `nanosleep' function is declared in `time.h'.  File: libc.info, Node: Resource Usage And Limitation, Next: Non-Local Exits, Prev: Date and Time, Up: Top Resource Usage And Limitation ***************************** This chapter describes functions for examining how much of various kinds of resources (CPU time, memory, etc.) a process has used and getting and setting limits on future usage. * Menu: * Resource Usage:: Measuring various resources used. * Limits on Resources:: Specifying limits on resource usage. * Priority:: Reading or setting process run priority. * Memory Resources:: Querying memory available resources. * Processor Resources:: Learn about the processors available.  File: libc.info, Node: Resource Usage, Next: Limits on Resources, Up: Resource Usage And Limitation Resource Usage ============== The function `getrusage' and the data type `struct rusage' are used to examine the resource usage of a process. They are declared in `sys/resource.h'. - Function: int getrusage (int PROCESSES, struct rusage *RUSAGE) This function reports resource usage totals for processes specified by PROCESSES, storing the information in `*RUSAGE'. In most systems, PROCESSES has only two valid values: `RUSAGE_SELF' Just the current process. `RUSAGE_CHILDREN' All child processes (direct and indirect) that have already terminated. In the GNU system, you can also inquire about a particular child process by specifying its process ID. The return value of `getrusage' is zero for success, and `-1' for failure. `EINVAL' The argument PROCESSES is not valid. One way of getting resource usage for a particular child process is with the function `wait4', which returns totals for a child when it terminates. *Note BSD Wait Functions::. - Data Type: struct rusage This data type stores various resource usage statistics. It has the following members, and possibly others: `struct timeval ru_utime' Time spent executing user instructions. `struct timeval ru_stime' Time spent in operating system code on behalf of PROCESSES. `long int ru_maxrss' The maximum resident set size used, in kilobytes. That is, the maximum number of kilobytes of physical memory that PROCESSES used simultaneously. `long int ru_ixrss' An integral value expressed in kilobytes times ticks of execution, which indicates the amount of memory used by text that was shared with other processes. `long int ru_idrss' An integral value expressed the same way, which is the amount of unshared memory used for data. `long int ru_isrss' An integral value expressed the same way, which is the amount of unshared memory used for stack space. `long int ru_minflt' The number of page faults which were serviced without requiring any I/O. `long int ru_majflt' The number of page faults which were serviced by doing I/O. `long int ru_nswap' The number of times PROCESSES was swapped entirely out of main memory. `long int ru_inblock' The number of times the file system had to read from the disk on behalf of PROCESSES. `long int ru_oublock' The number of times the file system had to write to the disk on behalf of PROCESSES. `long int ru_msgsnd' Number of IPC messages sent. `long int ru_msgrcv' Number of IPC messages received. `long int ru_nsignals' Number of signals received. `long int ru_nvcsw' The number of times PROCESSES voluntarily invoked a context switch (usually to wait for some service). `long int ru_nivcsw' The number of times an involuntary context switch took place (because a time slice expired, or another process of higher priority was scheduled). `vtimes' is a historical function that does some of what `getrusage' does. `getrusage' is a better choice. `vtimes' and its `vtimes' data structure are declared in `sys/vtimes.h'. - Function: int vtimes (struct vtimes CURRENT, struct vtimes CHILD) `vtimes' reports resource usage totals for a process. If CURRENT is non-null, `vtimes' stores resource usage totals for the invoking process alone in the structure to which it points. If CHILD is non-null, `vtimes' stores resource usage totals for all past children (which have terminated) of the invoking process in the structure to which it points. - Data Type: struct vtimes This data type contains information about the resource usage of a process. Each member corresponds to a member of the `struct rusage' data type described above. `vm_utime' User CPU time. Analogous to `ru_utime' in `struct rusage' `vm_stime' System CPU time. Analogous to `ru_stime' in `struct rusage' `vm_idsrss' Data and stack memory. The sum of the values that would be reported as `ru_idrss' and `ru_isrss' in `struct rusage' `vm_ixrss' Shared memory. Analogous to `ru_ixrss' in `struct rusage' `vm_maxrss' Maximent resident set size. Analogous to `ru_maxrss' in `struct rusage' `vm_majflt' Major page faults. Analogous to `ru_majflt' in `struct rusage' `vm_minflt' Minor page faults. Analogous to `ru_minflt' in `struct rusage' `vm_nswap' Swap count. Analogous to `ru_nswap' in `struct rusage' `vm_inblk' Disk reads. Analogous to `ru_inblk' in `struct rusage' `vm_oublk' Disk writes. Analogous to `ru_oublk' in `struct rusage' The return value is zero if the function succeeds; `-1' otherwise. An additional historical function for examining resource usage, `vtimes', is supported but not documented here. It is declared in `sys/vtimes.h'.  File: libc.info, Node: Limits on Resources, Next: Priority, Prev: Resource Usage, Up: Resource Usage And Limitation Limiting Resource Usage ======================= You can specify limits for the resource usage of a process. When the process tries to exceed a limit, it may get a signal, or the system call by which it tried to do so may fail, depending on the resource. Each process initially inherits its limit values from its parent, but it can subsequently change them. There are two per-process limits associated with a resource: "current limit" The current limit is the value the system will not allow usage to exceed. It is also called the "soft limit" because the process being limited can generally raise the current limit at will. "maximum limit" The maximum limit is the maximum value to which a process is allowed to set its current limit. It is also called the "hard limit" because there is no way for a process to get around it. A process may lower its own maximum limit, but only the superuser may increase a maximum limit. The symbols for use with `getrlimit', `setrlimit', `getrlimit64', and `setrlimit64' are defined in `sys/resource.h'. - Function: int getrlimit (int RESOURCE, struct rlimit *RLP) Read the current and maximum limits for the resource RESOURCE and store them in `*RLP'. The return value is `0' on success and `-1' on failure. The only possible `errno' error condition is `EFAULT'. When the sources are compiled with `_FILE_OFFSET_BITS == 64' on a 32-bit system this function is in fact `getrlimit64'. Thus, the LFS interface transparently replaces the old interface. - Function: int getrlimit64 (int RESOURCE, struct rlimit64 *RLP) This function is similar to `getrlimit' but its second parameter is a pointer to a variable of type `struct rlimit64', which allows it to read values which wouldn't fit in the member of a `struct rlimit'. If the sources are compiled with `_FILE_OFFSET_BITS == 64' on a 32-bit machine, this function is available under the name `getrlimit' and so transparently replaces the old interface. - Function: int setrlimit (int RESOURCE, const struct rlimit *RLP) Store the current and maximum limits for the resource RESOURCE in `*RLP'. The return value is `0' on success and `-1' on failure. The following `errno' error condition is possible: `EPERM' * The process tried to raise a current limit beyond the maximum limit. * The process tried to raise a maximum limit, but is not superuser. When the sources are compiled with `_FILE_OFFSET_BITS == 64' on a 32-bit system this function is in fact `setrlimit64'. Thus, the LFS interface transparently replaces the old interface. - Function: int setrlimit64 (int RESOURCE, const struct rlimit64 *RLP) This function is similar to `setrlimit' but its second parameter is a pointer to a variable of type `struct rlimit64' which allows it to set values which wouldn't fit in the member of a `struct rlimit'. If the sources are compiled with `_FILE_OFFSET_BITS == 64' on a 32-bit machine this function is available under the name `setrlimit' and so transparently replaces the old interface. - Data Type: struct rlimit This structure is used with `getrlimit' to receive limit values, and with `setrlimit' to specify limit values for a particular process and resource. It has two fields: `rlim_t rlim_cur' The current limit `rlim_t rlim_max' The maximum limit. For `getrlimit', the structure is an output; it receives the current values. For `setrlimit', it specifies the new values. For the LFS functions a similar type is defined in `sys/resource.h'. - Data Type: struct rlimit64 This structure is analogous to the `rlimit' structure above, but its components have wider ranges. It has two fields: `rlim64_t rlim_cur' This is analogous to `rlimit.rlim_cur', but with a different type. `rlim64_t rlim_max' This is analogous to `rlimit.rlim_max', but with a different type. Here is a list of resources for which you can specify a limit. Memory and file sizes are measured in bytes. `RLIMIT_CPU' The maximum amount of CPU time the process can use. If it runs for longer than this, it gets a signal: `SIGXCPU'. The value is measured in seconds. *Note Operation Error Signals::. `RLIMIT_FSIZE' The maximum size of file the process can create. Trying to write a larger file causes a signal: `SIGXFSZ'. *Note Operation Error Signals::. `RLIMIT_DATA' The maximum size of data memory for the process. If the process tries to allocate data memory beyond this amount, the allocation function fails. `RLIMIT_STACK' The maximum stack size for the process. If the process tries to extend its stack past this size, it gets a `SIGSEGV' signal. *Note Program Error Signals::. `RLIMIT_CORE' The maximum size core file that this process can create. If the process terminates and would dump a core file larger than this, then no core file is created. So setting this limit to zero prevents core files from ever being created. `RLIMIT_RSS' The maximum amount of physical memory that this process should get. This parameter is a guide for the system's scheduler and memory allocator; the system may give the process more memory when there is a surplus. `RLIMIT_MEMLOCK' The maximum amount of memory that can be locked into physical memory (so it will never be paged out). `RLIMIT_NPROC' The maximum number of processes that can be created with the same user ID. If you have reached the limit for your user ID, `fork' will fail with `EAGAIN'. *Note Creating a Process::. `RLIMIT_NOFILE' `RLIMIT_OFILE' The maximum number of files that the process can open. If it tries to open more files than this, its open attempt fails with `errno' `EMFILE'. *Note Error Codes::. Not all systems support this limit; GNU does, and 4.4 BSD does. `RLIMIT_AS' The maximum size of total memory that this process should get. If the process tries to allocate more memory beyond this amount with, for example, `brk', `malloc', `mmap' or `sbrk', the allocation function fails. `RLIM_NLIMITS' The number of different resource limits. Any valid RESOURCE operand must be less than `RLIM_NLIMITS'. - Constant: int RLIM_INFINITY This constant stands for a value of "infinity" when supplied as the limit value in `setrlimit'. The following are historical functions to do some of what the functions above do. The functions above are better choices. `ulimit' and the command symbols are declared in `ulimit.h'. - Function: int ulimit (int CMD, ...) `ulimit' gets the current limit or sets the current and maximum limit for a particular resource for the calling process according to the command CMD.a If you are getting a limit, the command argument is the only argument. If you are setting a limit, there is a second argument: `long int' LIMIT which is the value to which you are setting the limit. The CMD values and the operations they specify are: `GETFSIZE' Get the current limit on the size of a file, in units of 512 bytes. `SETFSIZE' Set the current and maximum limit on the size of a file to LIMIT * 512 bytes. There are also some other CMD values that may do things on some systems, but they are not supported. Only the superuser may increase a maximum limit. When you successfully get a limit, the return value of `ulimit' is that limit, which is never negative. When you successfully set a limit, the return value is zero. When the function fails, the return value is `-1' and `errno' is set according to the reason: `EPERM' A process tried to increase a maximum limit, but is not superuser. `vlimit' and its resource symbols are declared in `sys/vlimit.h'. - Function: int vlimit (int RESOURCE, int LIMIT) `vlimit' sets the current limit for a resource for a process. RESOURCE identifies the resource: `LIM_CPU' Maximum CPU time. Same as `RLIMIT_CPU' for `setrlimit'. `LIM_FSIZE' Maximum file size. Same as `RLIMIT_FSIZE' for `setrlimit'. `LIM_DATA' Maximum data memory. Same as `RLIMIT_DATA' for `setrlimit'. `LIM_STACK' Maximum stack size. Same as `RLIMIT_STACK' for `setrlimit'. `LIM_CORE' Maximum core file size. Same as `RLIMIT_COR' for `setrlimit'. `LIM_MAXRSS' Maximum physical memory. Same as `RLIMIT_RSS' for `setrlimit'. The return value is zero for success, and `-1' with `errno' set accordingly for failure: `EPERM' The process tried to set its current limit beyond its maximum limit.  File: libc.info, Node: Priority, Next: Memory Resources, Prev: Limits on Resources, Up: Resource Usage And Limitation Process CPU Priority And Scheduling =================================== When multiple processes simultaneously require CPU time, the system's scheduling policy and process CPU priorities determine which processes get it. This section describes how that determination is made and GNU C library functions to control it. It is common to refer to CPU scheduling simply as scheduling and a process' CPU priority simply as the process' priority, with the CPU resource being implied. Bear in mind, though, that CPU time is not the only resource a process uses or that processes contend for. In some cases, it is not even particularly important. Giving a process a high "priority" may have very little effect on how fast a process runs with respect to other processes. The priorities discussed in this section apply only to CPU time. CPU scheduling is a complex issue and different systems do it in wildly different ways. New ideas continually develop and find their way into the intricacies of the various systems' scheduling algorithms. This section discusses the general concepts, some specifics of systems that commonly use the GNU C library, and some standards. For simplicity, we talk about CPU contention as if there is only one CPU in the system. But all the same principles apply when a processor has multiple CPUs, and knowing that the number of processes that can run at any one time is equal to the number of CPUs, you can easily extrapolate the information. The functions described in this section are all defined by the POSIX.1 and POSIX.1b standards (the `sched...' functions are POSIX.1b). However, POSIX does not define any semantics for the values that these functions get and set. In this chapter, the semantics are based on the Linux kernel's implementation of the POSIX standard. As you will see, the Linux implementation is quite the inverse of what the authors of the POSIX syntax had in mind. * Menu: * Absolute Priority:: The first tier of priority. Posix * Realtime Scheduling:: Scheduling among the process nobility * Basic Scheduling Functions:: Get/set scheduling policy, priority * Traditional Scheduling:: Scheduling among the vulgar masses  File: libc.info, Node: Absolute Priority, Next: Realtime Scheduling, Up: Priority Absolute Priority ----------------- Every process has an absolute priority, and it is represented by a number. The higher the number, the higher the absolute priority. On systems of the past, and most systems today, all processes have absolute priority 0 and this section is irrelevant. In that case, *Note Traditional Scheduling::. Absolute priorities were invented to accommodate realtime systems, in which it is vital that certain processes be able to respond to external events happening in real time, which means they cannot wait around while some other process that _wants to_, but doesn't _need to_ run occupies the CPU. When two processes are in contention to use the CPU at any instant, the one with the higher absolute priority always gets it. This is true even if the process with the lower priority is already using the CPU (i.e. the scheduling is preemptive). Of course, we're only talking about processes that are running or "ready to run," which means they are ready to execute instructions right now. When a process blocks to wait for something like I/O, its absolute priority is irrelevant. *Note:* The term "runnable" is a synonym for "ready to run." When two processes are running or ready to run and both have the same absolute priority, it's more interesting. In that case, who gets the CPU is determined by the scheduling policy. If the processes have absolute priority 0, the traditional scheduling policy described in *Note Traditional Scheduling:: applies. Otherwise, the policies described in *Note Realtime Scheduling:: apply. You normally give an absolute priority above 0 only to a process that can be trusted not to hog the CPU. Such processes are designed to block (or terminate) after relatively short CPU runs. A process begins life with the same absolute priority as its parent process. Functions described in *Note Basic Scheduling Functions:: can change it. Only a privileged process can change a process' absolute priority to something other than `0'. Only a privileged process or the target process' owner can change its absolute priority at all. POSIX requires absolute priority values used with the realtime scheduling policies to be consecutive with a range of at least 32. On Linux, they are 1 through 99. The functions `sched_get_priority_max' and `sched_set_priority_min' portably tell you what the range is on a particular system. Using Absolute Priority ....................... One thing you must keep in mind when designing real time applications is that having higher absolute priority than any other process doesn't guarantee the process can run continuously. Two things that can wreck a good CPU run are interrupts and page faults. Interrupt handlers live in that limbo between processes. The CPU is executing instructions, but they aren't part of any process. An interrupt will stop even the highest priority process. So you must allow for slight delays and make sure that no device in the system has an interrupt handler that could cause too long a delay between instructions for your process. Similarly, a page fault causes what looks like a straightforward sequence of instructions to take a long time. The fact that other processes get to run while the page faults in is of no consequence, because as soon as the I/O is complete, the high priority process will kick them out and run again, but the wait for the I/O itself could be a problem. To neutralize this threat, use `mlock' or `mlockall'. There are a few ramifications of the absoluteness of this priority on a single-CPU system that you need to keep in mind when you choose to set a priority and also when you're working on a program that runs with high absolute priority. Consider a process that has higher absolute priority than any other process in the system and due to a bug in its program, it gets into an infinite loop. It will never cede the CPU. You can't run a command to kill it because your command would need to get the CPU in order to run. The errant program is in complete control. It controls the vertical, it controls the horizontal. There are two ways to avoid this: 1) keep a shell running somewhere with a higher absolute priority. 2) keep a controlling terminal attached to the high priority process group. All the priority in the world won't stop an interrupt handler from running and delivering a signal to the process if you hit Control-C. Some systems use absolute priority as a means of allocating a fixed percentage of CPU time to a process. To do this, a super high priority privileged process constantly monitors the process' CPU usage and raises its absolute priority when the process isn't getting its entitled share and lowers it when the process is exceeding it. *Note:* The absolute priority is sometimes called the "static priority." We don't use that term in this manual because it misses the most important feature of the absolute priority: its absoluteness.  File: libc.info, Node: Realtime Scheduling, Next: Basic Scheduling Functions, Prev: Absolute Priority, Up: Priority Realtime Scheduling ------------------- Whenever two processes with the same absolute priority are ready to run, the kernel has a decision to make, because only one can run at a time. If the processes have absolute priority 0, the kernel makes this decision as described in *Note Traditional Scheduling::. Otherwise, the decision is as described in this section. If two processes are ready to run but have different absolute priorities, the decision is much simpler, and is described in *Note Absolute Priority::. Each process has a scheduling policy. For processes with absolute priority other than zero, there are two available: 1. First Come First Served 2. Round Robin The most sensible case is where all the processes with a certain absolute priority have the same scheduling policy. We'll discuss that first. In Round Robin, processes share the CPU, each one running for a small quantum of time ("time slice") and then yielding to another in a circular fashion. Of course, only processes that are ready to run and have the same absolute priority are in this circle. In First Come First Served, the process that has been waiting the longest to run gets the CPU, and it keeps it until it voluntarily relinquishes the CPU, runs out of things to do (blocks), or gets preempted by a higher priority process. First Come First Served, along with maximal absolute priority and careful control of interrupts and page faults, is the one to use when a process absolutely, positively has to run at full CPU speed or not at all. Judicious use of `sched_yield' function invocations by processes with First Come First Served scheduling policy forms a good compromise between Round Robin and First Come First Served. To understand how scheduling works when processes of different scheduling policies occupy the same absolute priority, you have to know the nitty gritty details of how processes enter and exit the ready to run list: In both cases, the ready to run list is organized as a true queue, where a process gets pushed onto the tail when it becomes ready to run and is popped off the head when the scheduler decides to run it. Note that ready to run and running are two mutually exclusive states. When the scheduler runs a process, that process is no longer ready to run and no longer in the ready to run list. When the process stops running, it may go back to being ready to run again. The only difference between a process that is assigned the Round Robin scheduling policy and a process that is assigned First Come First Serve is that in the former case, the process is automatically booted off the CPU after a certain amount of time. When that happens, the process goes back to being ready to run, which means it enters the queue at the tail. The time quantum we're talking about is small. Really small. This is not your father's timesharing. For example, with the Linux kernel, the round robin time slice is a thousand times shorter than its typical time slice for traditional scheduling. A process begins life with the same scheduling policy as its parent process. Functions described in *Note Basic Scheduling Functions:: can change it. Only a privileged process can set the scheduling policy of a process that has absolute priority higher than 0.  File: libc.info, Node: Basic Scheduling Functions, Next: Traditional Scheduling, Prev: Realtime Scheduling, Up: Priority Basic Scheduling Functions -------------------------- This section describes functions in the GNU C library for setting the absolute priority and scheduling policy of a process. *Portability Note:* On systems that have the functions in this section, the macro _POSIX_PRIORITY_SCHEDULING is defined in `'. For the case that the scheduling policy is traditional scheduling, more functions to fine tune the scheduling are in *Note Traditional Scheduling::. Don't try to make too much out of the naming and structure of these functions. They don't match the concepts described in this manual because the functions are as defined by POSIX.1b, but the implementation on systems that use the GNU C library is the inverse of what the POSIX structure contemplates. The POSIX scheme assumes that the primary scheduling parameter is the scheduling policy and that the priority value, if any, is a parameter of the scheduling policy. In the implementation, though, the priority value is king and the scheduling policy, if anything, only fine tunes the effect of that priority. The symbols in this section are declared by including file `sched.h'. - Data Type: struct sched_param This structure describes an absolute priority. `int sched_priority' absolute priority value - Function: int sched_setscheduler (pid_t PID, int POLICY, const struct sched_param *PARAM) This function sets both the absolute priority and the scheduling policy for a process. It assigns the absolute priority value given by PARAM and the scheduling policy POLICY to the process with Process ID PID, or the calling process if PID is zero. If POLICY is negative, `sched_setscheduler' keeps the existing scheduling policy. The following macros represent the valid values for POLICY: `SCHED_OTHER' Traditional Scheduling `SCHED_FIFO' First In First Out `SCHED_RR' Round Robin On success, the return value is `0'. Otherwise, it is `-1' and `ERRNO' is set accordingly. The `errno' values specific to this function are: `EPERM' * The calling process does not have `CAP_SYS_NICE' permission and POLICY is not `SCHED_OTHER' (or it's negative and the existing policy is not `SCHED_OTHER'. * The calling process does not have `CAP_SYS_NICE' permission and its owner is not the target process' owner. I.e. the effective uid of the calling process is neither the effective nor the real uid of process PID. `ESRCH' There is no process with pid PID and PID is not zero. `EINVAL' * POLICY does not identify an existing scheduling policy. * The absolute priority value identified by *PARAM is outside the valid range for the scheduling policy POLICY (or the existing scheduling policy if POLICY is negative) or PARAM is null. `sched_get_priority_max' and `sched_get_priority_min' tell you what the valid range is. * PID is negative. - Function: int sched_getscheduler (pid_t PID) This function returns the scheduling policy assigned to the process with Process ID (pid) PID, or the calling process if PID is zero. The return value is the scheduling policy. See `sched_setscheduler' for the possible values. If the function fails, the return value is instead `-1' and `errno' is set accordingly. The `errno' values specific to this function are: `ESRCH' There is no process with pid PID and it is not zero. `EINVAL' PID is negative. Note that this function is not an exact mate to `sched_setscheduler' because while that function sets the scheduling policy and the absolute priority, this function gets only the scheduling policy. To get the absolute priority, use `sched_getparam'. - Function: int sched_setparam (pid_t PID, const struct sched_param *PARAM) This function sets a process' absolute priority. It is functionally identical to `sched_setscheduler' with POLICY = `-1'. - Function: int sched_getparam (pid_t PID, const struct sched_param *PARAM) This function returns a process' absolute priority. PID is the Process ID (pid) of the process whose absolute priority you want to know. PARAM is a pointer to a structure in which the function stores the absolute priority of the process. On success, the return value is `0'. Otherwise, it is `-1' and `ERRNO' is set accordingly. The `errno' values specific to this function are: `ESRCH' There is no process with pid PID and it is not zero. `EINVAL' PID is negative. - Function: int sched_get_priority_min (int *POLICY); This function returns the lowest absolute priority value that is allowable for a process with scheduling policy POLICY. On Linux, it is 0 for SCHED_OTHER and 1 for everything else. On success, the return value is `0'. Otherwise, it is `-1' and `ERRNO' is set accordingly. The `errno' values specific to this function are: `EINVAL' POLICY does not identify an existing scheduling policy. - Function: int sched_get_priority_max (int *POLICY); This function returns the highest absolute priority value that is allowable for a process that with scheduling policy POLICY. On Linux, it is 0 for SCHED_OTHER and 99 for everything else. On success, the return value is `0'. Otherwise, it is `-1' and `ERRNO' is set accordingly. The `errno' values specific to this function are: `EINVAL' POLICY does not identify an existing scheduling policy. - Function: int sched_rr_get_interval (pid_t PID, struct timespec *INTERVAL) This function returns the length of the quantum (time slice) used with the Round Robin scheduling policy, if it is used, for the process with Process ID PID. It returns the length of time as INTERVAL. With a Linux kernel, the round robin time slice is always 150 microseconds, and PID need not even be a real pid. The return value is `0' on success and in the pathological case that it fails, the return value is `-1' and `errno' is set accordingly. There is nothing specific that can go wrong with this function, so there are no specific `errno' values. - Function: int sched_yield (void) This function voluntarily gives up the process' claim on the CPU. Technically, `sched_yield' causes the calling process to be made immediately ready to run (as opposed to running, which is what it was before). This means that if it has absolute priority higher than 0, it gets pushed onto the tail of the queue of processes that share its absolute priority and are ready to run, and it will run again when its turn next arrives. If its absolute priority is 0, it is more complicated, but still has the effect of yielding the CPU to other processes. If there are no other processes that share the calling process' absolute priority, this function doesn't have any effect. To the extent that the containing program is oblivious to what other processes in the system are doing and how fast it executes, this function appears as a no-op. The return value is `0' on success and in the pathological case that it fails, the return value is `-1' and `errno' is set accordingly. There is nothing specific that can go wrong with this function, so there are no specific `errno' values.  File: libc.info, Node: Traditional Scheduling, Prev: Basic Scheduling Functions, Up: Priority Traditional Scheduling ---------------------- This section is about the scheduling among processes whose absolute priority is 0. When the system hands out the scraps of CPU time that are left over after the processes with higher absolute priority have taken all they want, the scheduling described herein determines who among the great unwashed processes gets them. * Menu: * Traditional Scheduling Intro:: * Traditional Scheduling Functions::  File: libc.info, Node: Traditional Scheduling Intro, Next: Traditional Scheduling Functions, Up: Traditional Scheduling Introduction To Traditional Scheduling ...................................... Long before there was absolute priority (See *Note Absolute Priority::), Unix systems were scheduling the CPU using this system. When Posix came in like the Romans and imposed absolute priorities to accommodate the needs of realtime processing, it left the indigenous Absolute Priority Zero processes to govern themselves by their own familiar scheduling policy. Indeed, absolute priorities higher than zero are not available on many systems today and are not typically used when they are, being intended mainly for computers that do realtime processing. So this section describes the only scheduling many programmers need to be concerned about. But just to be clear about the scope of this scheduling: Any time a process with a absolute priority of 0 and a process with an absolute priority higher than 0 are ready to run at the same time, the one with absolute priority 0 does not run. If it's already running when the higher priority ready-to-run process comes into existence, it stops immediately. In addition to its absolute priority of zero, every process has another priority, which we will refer to as "dynamic priority" because it changes over time. The dynamic priority is meaningless for processes with an absolute priority higher than zero. The dynamic priority sometimes determines who gets the next turn on the CPU. Sometimes it determines how long turns last. Sometimes it determines whether a process can kick another off the CPU. In Linux, the value is a combination of these things, but mostly it is just determines the length of the time slice. The higher a process' dynamic priority, the longer a shot it gets on the CPU when it gets one. If it doesn't use up its time slice before giving up the CPU to do something like wait for I/O, it is favored for getting the CPU back when it's ready for it, to finish out its time slice. Other than that, selection of processes for new time slices is basically round robin. But the scheduler does throw a bone to the low priority processes: A process' dynamic priority rises every time it is snubbed in the scheduling process. In Linux, even the fat kid gets to play. The fluctuation of a process' dynamic priority is regulated by another value: The "nice" value. The nice value is an integer, usually in the range -20 to 20, and represents an upper limit on a process' dynamic priority. The higher the nice number, the lower that limit. On a typical Linux system, for example, a process with a nice value of 20 can get only 10 milliseconds on the CPU at a time, whereas a process with a nice value of -20 can achieve a high enough priority to get 400 milliseconds. The idea of the nice value is deferential courtesy. In the beginning, in the Unix garden of Eden, all processes shared equally in the bounty of the computer system. But not all processes really need the same share of CPU time, so the nice value gave a courteous process the ability to refuse its equal share of CPU time that others might prosper. Hence, the higher a process' nice value, the nicer the process is. (Then a snake came along and offered some process a negative nice value and the system became the crass resource allocation system we know today). Dynamic priorities tend upward and downward with an objective of smoothing out allocation of CPU time and giving quick response time to infrequent requests. But they never exceed their nice limits, so on a heavily loaded CPU, the nice value effectively determines how fast a process runs. In keeping with the socialistic heritage of Unix process priority, a process begins life with the same nice value as its parent process and can raise it at will. A process can also raise the nice value of any other process owned by the same user (or effective user). But only a privileged process can lower its nice value. A privileged process can also raise or lower another process' nice value. GNU C Library functions for getting and setting nice values are described in *Note Traditional Scheduling Functions::.  File: libc.info, Node: Traditional Scheduling Functions, Prev: Traditional Scheduling Intro, Up: Traditional Scheduling Functions For Traditional Scheduling .................................... This section describes how you can read and set the nice value of a process. All these symbols are declared in `sys/resource.h'. The function and macro names are defined by POSIX, and refer to "priority," but the functions actually have to do with nice values, as the terms are used both in the manual and POSIX. The range of valid nice values depends on the kernel, but typically it runs from `-20' to `20'. A lower nice value corresponds to higher priority for the process. These constants describe the range of priority values: `PRIO_MIN' The lowest valid nice value. `PRIO_MAX' The highest valid nice value. - Function: int getpriority (int CLASS, int ID) Return the nice value of a set of processes; CLASS and ID specify which ones (see below). If the processes specified do not all have the same nice value, this returns the lowest value that any of them has. On success, the return value is `0'. Otherwise, it is `-1' and `ERRNO' is set accordingly. The `errno' values specific to this function are: `ESRCH' The combination of CLASS and ID does not match any existing process. `EINVAL' The value of CLASS is not valid. If the return value is `-1', it could indicate failure, or it could be the nice value. The only way to make certain is to set `errno = 0' before calling `getpriority', then use `errno != 0' afterward as the criterion for failure. - Function: int setpriority (int CLASS, int ID, int NICEVAL) Set the nice value of a set of processes to NICEVAL; CLASS and ID specify which ones (see below). The return value is `0' on success, and `-1' on failure. The following `errno' error condition are possible for this function: `ESRCH' The combination of CLASS and ID does not match any existing process. `EINVAL' The value of CLASS is not valid. `EPERM' The call would set the nice value of a process which is owned by a different user than the calling process (i.e. the target process' real or effective uid does not match the calling process' effective uid) and the calling process does not have `CAP_SYS_NICE' permission. `EACCES' The call would lower the process' nice value and the process does not have `CAP_SYS_NICE' permission. The arguments CLASS and ID together specify a set of processes in which you are interested. These are the possible values of CLASS: `PRIO_PROCESS' One particular process. The argument ID is a process ID (pid). `PRIO_PGRP' All the processes in a particular process group. The argument ID is a process group ID (pgid). `PRIO_USER' All the processes owned by a particular user (i.e. whose real uid indicates the user). The argument ID is a user ID (uid). If the argument ID is 0, it stands for the calling process, its process group, or its owner (real uid), according to CLASS. - Function: int nice (int INCREMENT) Increment the nice value of the calling process by INCREMENT. The return value is the new nice value on success, and `-1' on failure. In the case of failure, `errno' will be set to the same values as for `setpriority'. Here is an equivalent definition of `nice': int nice (int increment) { int result, old = getpriority (PRIO_PROCESS, 0); result = setpriority (PRIO_PROCESS, 0, old + increment); if (result != -1) return old + increment; else return -1; }  File: libc.info, Node: Memory Resources, Next: Processor Resources, Prev: Priority, Up: Resource Usage And Limitation Querying memory available resources =================================== The amount of memory available in the system and the way it is organized determines oftentimes the way programs can and have to work. For functions like `mmap' it is necessary to know about the size of individual memory pages and knowing how much memory is available enables a program to select appropriate sizes for, say, caches. Before we get into these details a few words about memory subsystems in traditional Unix systems will be given. * Menu: * Memory Subsystem:: Overview about traditional Unix memory handling. * Query Memory Parameters:: How to get information about the memory subsystem?  File: libc.info, Node: Memory Subsystem, Next: Query Memory Parameters, Up: Memory Resources Overview about traditional Unix memory handling ----------------------------------------------- Unix systems normally provide processes virtual address spaces. This means that the addresses of the memory regions do not have to correspond directly to the addresses of the actual physical memory which stores the data. An extra level of indirection is introduced which translates virtual addresses into physical addresses. This is normally done by the hardware of the processor. Using a virtual address space has several advantage. The most important is process isolation. The different processes running on the system cannot interfere directly with each other. No process can write into the address space of another process (except when shared memory is used but then it is wanted and controlled). Another advantage of virtual memory is that the address space the processes see can actually be larger than the physical memory available. The physical memory can be extended by storage on an external media where the content of currently unused memory regions is stored. The address translation can then intercept accesses to these memory regions and make memory content available again by loading the data back into memory. This concept makes it necessary that programs which have to use lots of memory know the difference between available virtual address space and available physical memory. If the working set of virtual memory of all the processes is larger than the available physical memory the system will slow down dramatically due to constant swapping of memory content from the memory to the storage media and back. This is called "thrashing". A final aspect of virtual memory which is important and follows from what is said in the last paragraph is the granularity of the virtual address space handling. When we said that the virtual address handling stores memory content externally it cannot do this on a byte-by-byte basis. The administrative overhead does not allow this (leaving alone the processor hardware). Instead several thousand bytes are handled together and form a "page". The size of each page is always a power of two byte. The smallest page size in use today is 4096, with 8192, 16384, and 65536 being other popular sizes.  File: libc.info, Node: Query Memory Parameters, Prev: Memory Subsystem, Up: Memory Resources How to get information about the memory subsystem? -------------------------------------------------- The page size of the virtual memory the process sees is essential to know in several situations. Some programming interface (e.g., `mmap', *note Memory-mapped I/O::) require the user to provide information adjusted to the page size. In the case of `mmap' is it necessary to provide a length argument which is a multiple of the page size. Another place where the knowledge about the page size is useful is in memory allocation. If one allocates pieces of memory in larger chunks which are then subdivided by the application code it is useful to adjust the size of the larger blocks to the page size. If the total memory requirement for the block is close (but not larger) to a multiple of the page size the kernel's memory handling can work more effectively since it only has to allocate memory pages which are fully used. (To do this optimization it is necessary to know a bit about the memory allocator which will require a bit of memory itself for each block and this overhead must not push the total size over the page size multiple. The page size traditionally was a compile time constant. But recent development of processors changed this. Processors now support different page sizes and they can possibly even vary among different processes on the same system. Therefore the system should be queried at runtime about the current page size and no assumptions (except about it being a power of two) should be made. The correct interface to query about the page size is `sysconf' (*note Sysconf Definition::) with the parameter `_SC_PAGESIZE'. There is a much older interface available, too. - Function: int getpagesize (void) The `getpagesize' function returns the page size of the process. This value is fixed for the runtime of the process but can vary in different runs of the application. The function is declared in `unistd.h'. Widely available on System V derived systems is a method to get information about the physical memory the system has. The call sysconf (_SC_PHYS_PAGES) returns the total number of pages of physical the system has. This does not mean all this memory is available. This information can be found using sysconf (_SC_AVPHYS_PAGES) These two values help to optimize applications. The value returned for `_SC_AVPHYS_PAGES' is the amount of memory the application can use without hindering any other process (given that no other process increases its memory usage). The value returned for `_SC_PHYS_PAGES' is more or less a hard limit for the working set. If all applications together constantly use more than that amount of memory the system is in trouble. The GNU C library provides in addition to these already described way to get this information two functions. They are declared in the file `sys/sysinfo.h'. Programmers should prefer to use the `sysconf' method described above. - Function: long int get_phys_pages (void) The `get_phys_pages' function returns the total number of pages of physical the system has. To get the amount of memory this number has to be multiplied by the page size. This function is a GNU extension. - Function: long int get_avphys_pages (void) The `get_phys_pages' function returns the number of available pages of physical the system has. To get the amount of memory this number has to be multiplied by the page size. This function is a GNU extension.  File: libc.info, Node: Processor Resources, Prev: Memory Resources, Up: Resource Usage And Limitation Learn about the processors available ==================================== The use of threads or processes with shared memory allows an application to take advantage of all the processing power a system can provide. If the task can be parallelized the optimal way to write an application is to have at any time as many processes running as there are processors. To determine the number of processors available to the system one can run sysconf (_SC_NPROCESSORS_CONF) which returns the number of processors the operating system configured. But it might be possible for the operating system to disable individual processors and so the call sysconf (_SC_NPROCESSORS_ONLN) returns the number of processors which are currently inline (i.e., available). For these two pieces of information the GNU C library also provides functions to get the information directly. The functions are declared in `sys/sysinfo.h'. - Function: int get_nprocs_conf (void) The `get_nprocs_conf' function returns the number of processors the operating system configured. This function is a GNU extension. - Function: int get_nprocs (void) The `get_nprocs' function returns the number of available processors. This function is a GNU extension. Before starting more threads it should be checked whether the processors are not already overused. Unix systems calculate something called the "load average". This is a number indicating how many processes were running. This number is average over different periods of times (normally 1, 5, and 15 minutes). - Function: int getloadavg (double LOADAVG[], int NELEM) This function gets the 1, 5 and 15 minute load averages of the system. The values are placed in LOADAVG. `getloadavg' will place at most NELEM elements into the array but never more than three elements. The return value is the number of elements written to LOADAVG, or -1 on error. This function is declared in `stdlib.h'.  File: libc.info, Node: Non-Local Exits, Next: Signal Handling, Prev: Resource Usage And Limitation, Up: Top Non-Local Exits *************** Sometimes when your program detects an unusual situation inside a deeply nested set of function calls, you would like to be able to immediately return to an outer level of control. This section describes how you can do such "non-local exits" using the `setjmp' and `longjmp' functions. * Menu: * Intro: Non-Local Intro. When and how to use these facilities. * Details: Non-Local Details. Functions for non-local exits. * Non-Local Exits and Signals:: Portability issues. * System V contexts:: Complete context control a la System V.  File: libc.info, Node: Non-Local Intro, Next: Non-Local Details, Up: Non-Local Exits Introduction to Non-Local Exits =============================== As an example of a situation where a non-local exit can be useful, suppose you have an interactive program that has a "main loop" that prompts for and executes commands. Suppose the "read" command reads input from a file, doing some lexical analysis and parsing of the input while processing it. If a low-level input error is detected, it would be useful to be able to return immediately to the "main loop" instead of having to make each of the lexical analysis, parsing, and processing phases all have to explicitly deal with error situations initially detected by nested calls. (On the other hand, if each of these phases has to do a substantial amount of cleanup when it exits--such as closing files, deallocating buffers or other data structures, and the like--then it can be more appropriate to do a normal return and have each phase do its own cleanup, because a non-local exit would bypass the intervening phases and their associated cleanup code entirely. Alternatively, you could use a non-local exit but do the cleanup explicitly either before or after returning to the "main loop".) In some ways, a non-local exit is similar to using the `return' statement to return from a function. But while `return' abandons only a single function call, transferring control back to the point at which it was called, a non-local exit can potentially abandon many levels of nested function calls. You identify return points for non-local exits by calling the function `setjmp'. This function saves information about the execution environment in which the call to `setjmp' appears in an object of type `jmp_buf'. Execution of the program continues normally after the call to `setjmp', but if an exit is later made to this return point by calling `longjmp' with the corresponding `jmp_buf' object, control is transferred back to the point where `setjmp' was called. The return value from `setjmp' is used to distinguish between an ordinary return and a return made by a call to `longjmp', so calls to `setjmp' usually appear in an `if' statement. Here is how the example program described above might be set up: #include #include #include jmp_buf main_loop; void abort_to_main_loop (int status) { longjmp (main_loop, status); } int main (void) { while (1) if (setjmp (main_loop)) puts ("Back at main loop...."); else do_command (); } void do_command (void) { char buffer[128]; if (fgets (buffer, 128, stdin) == NULL) abort_to_main_loop (-1); else exit (EXIT_SUCCESS); } The function `abort_to_main_loop' causes an immediate transfer of control back to the main loop of the program, no matter where it is called from. The flow of control inside the `main' function may appear a little mysterious at first, but it is actually a common idiom with `setjmp'. A normal call to `setjmp' returns zero, so the "else" clause of the conditional is executed. If `abort_to_main_loop' is called somewhere within the execution of `do_command', then it actually appears as if the _same_ call to `setjmp' in `main' were returning a second time with a value of `-1'. So, the general pattern for using `setjmp' looks something like: if (setjmp (BUFFER)) /* Code to clean up after premature return. */ ... else /* Code to be executed normally after setting up the return point. */ ...  File: libc.info, Node: Non-Local Details, Next: Non-Local Exits and Signals, Prev: Non-Local Intro, Up: Non-Local Exits Details of Non-Local Exits ========================== Here are the details on the functions and data structures used for performing non-local exits. These facilities are declared in `setjmp.h'. - Data Type: jmp_buf Objects of type `jmp_buf' hold the state information to be restored by a non-local exit. The contents of a `jmp_buf' identify a specific place to return to. - Macro: int setjmp (jmp_buf STATE) When called normally, `setjmp' stores information about the execution state of the program in STATE and returns zero. If `longjmp' is later used to perform a non-local exit to this STATE, `setjmp' returns a nonzero value. - Function: void longjmp (jmp_buf STATE, int VALUE) This function restores current execution to the state saved in STATE, and continues execution from the call to `setjmp' that established that return point. Returning from `setjmp' by means of `longjmp' returns the VALUE argument that was passed to `longjmp', rather than `0'. (But if VALUE is given as `0', `setjmp' returns `1'). There are a lot of obscure but important restrictions on the use of `setjmp' and `longjmp'. Most of these restrictions are present because non-local exits require a fair amount of magic on the part of the C compiler and can interact with other parts of the language in strange ways. The `setjmp' function is actually a macro without an actual function definition, so you shouldn't try to `#undef' it or take its address. In addition, calls to `setjmp' are safe in only the following contexts: * As the test expression of a selection or iteration statement (such as `if', `switch', or `while'). * As one operand of a equality or comparison operator that appears as the test expression of a selection or iteration statement. The other operand must be an integer constant expression. * As the operand of a unary `!' operator, that appears as the test expression of a selection or iteration statement. * By itself as an expression statement. Return points are valid only during the dynamic extent of the function that called `setjmp' to establish them. If you `longjmp' to a return point that was established in a function that has already returned, unpredictable and disastrous things are likely to happen. You should use a nonzero VALUE argument to `longjmp'. While `longjmp' refuses to pass back a zero argument as the return value from `setjmp', this is intended as a safety net against accidental misuse and is not really good programming style. When you perform a non-local exit, accessible objects generally retain whatever values they had at the time `longjmp' was called. The exception is that the values of automatic variables local to the function containing the `setjmp' call that have been changed since the call to `setjmp' are indeterminate, unless you have declared them `volatile'.  File: libc.info, Node: Non-Local Exits and Signals, Next: System V contexts, Prev: Non-Local Details, Up: Non-Local Exits Non-Local Exits and Signals =========================== In BSD Unix systems, `setjmp' and `longjmp' also save and restore the set of blocked signals; see *Note Blocking Signals::. However, the POSIX.1 standard requires `setjmp' and `longjmp' not to change the set of blocked signals, and provides an additional pair of functions (`sigsetjmp' and `siglongjmp') to get the BSD behavior. The behavior of `setjmp' and `longjmp' in the GNU library is controlled by feature test macros; see *Note Feature Test Macros::. The default in the GNU system is the POSIX.1 behavior rather than the BSD behavior. The facilities in this section are declared in the header file `setjmp.h'. - Data Type: sigjmp_buf This is similar to `jmp_buf', except that it can also store state information about the set of blocked signals. - Function: int sigsetjmp (sigjmp_buf STATE, int SAVESIGS) This is similar to `setjmp'. If SAVESIGS is nonzero, the set of blocked signals is saved in STATE and will be restored if a `siglongjmp' is later performed with this STATE. - Function: void siglongjmp (sigjmp_buf STATE, int VALUE) This is similar to `longjmp' except for the type of its STATE argument. If the `sigsetjmp' call that set this STATE used a nonzero SAVESIGS flag, `siglongjmp' also restores the set of blocked signals.  File: libc.info, Node: System V contexts, Prev: Non-Local Exits and Signals, Up: Non-Local Exits Complete Context Control ======================== The Unix standard one more set of function to control the execution path and these functions are more powerful than those discussed in this chapter so far. These function were part of the original System V API and by this route were added to the Unix API. Beside on branded Unix implementations these interfaces are not widely available. Not all platforms and/or architectures the GNU C Library is available on provide this interface. Use `configure' to detect the availability. Similar to the `jmp_buf' and `sigjmp_buf' types used for the variables to contain the state of the `longjmp' functions the interfaces of interest here have an appropriate type as well. Objects of this type are normally much larger since more information is contained. The type is also used in a few more places as we will see. The types and functions described in this section are all defined and declared respectively in the `ucontext.h' header file. - Data Type: ucontext_t The `ucontext_t' type is defined as a structure with as least the following elements: `ucontext_t *uc_link' This is a pointer to the next context structure which is used if the context described in the current structure returns. `sigset_t uc_sigmask' Set of signals which are blocked when this context is used. `stack_t uc_stack' Stack used for this context. The value need not be (and normally is not) the stack pointer. *Note Signal Stack::. `mcontext_t uc_mcontext' This element contains the actual state of the process. The `mcontext_t' type is also defined in this header but the definition should be treated as opaque. Any use of knowledge of the type makes applications less portable. Objects of this type have to be created by the user. The initialization and modification happens through one of the following functions: - Function: int getcontext (ucontext_t *UCP) The `getcontext' function initializes the variable pointed to by UCP with the context of the calling thread. The context contains the content of the registers, the signal mask, and the current stack. Executing the contents would start at the point where the `getcontext' call just returned. The function returns `0' if successful. Otherwise it returns `-1' and sets ERRNO accordingly. The `getcontext' function is similar to `setjmp' but it does not provide an indication of whether the function returns for the first time or whether the initialized context was used and the execution is resumed at just that point. If this is necessary the user has to take determine this herself. This must be done carefully since the context contains registers which might contain register variables. This is a good situation to define variables with `volatile'. Once the context variable is initialized it can be used as is or it can be modified. The latter is normally done to implement co-routines or similar constructs. The `makecontext' function is what has to be used to do that. - Function: void makecontext (ucontext_t *UCP, void (*FUNC) (void), int ARGC, ...) The UCP parameter passed to the `makecontext' shall be initialized by a call to `getcontext'. The context will be modified to in a way so that if the context is resumed it will start by calling the function `func' which gets ARGC integer arguments passed. The integer arguments which are to be passed should follow the ARGC parameter in the call to `makecontext'. Before the call to this function the `uc_stack' and `uc_link' element of the UCP structure should be initialized. The `uc_stack' element describes the stack which is used for this context. No two contexts which are used at the same time should use the same memory region for a stack. The `uc_link' element of the object pointed to by UCP should be a pointer to the context to be executed when the function FUNC returns or it should be a null pointer. See `setcontext' for more information about the exact use. While allocating the memory for the stack one has to be careful. Most modern processors keep track of whether a certain memory region is allowed to contain code which is executed or not. Data segments and heap memory is normally not tagged to allow this. The result is that programs would fail. Examples for such code include the calling sequences the GNU C compiler generates for calls to nested functions. Safe ways to allocate stacks correctly include using memory on the original threads stack or explicitly allocate memory tagged for execution using (*note Memory-mapped I/O::). *Compatibility note*: The current Unix standard is very imprecise about the way the stack is allocated. All implementations seem to agree that the `uc_stack' element must be used but the values stored in the elements of the `stack_t' value are unclear. The GNU C library and most other Unix implementations require the `ss_sp' value of the `uc_stack' element to point to the base of the memory region allocated for the stack and the size of the memory region is stored in `ss_size'. There are implements out there which require `ss_sp' to be set to the value the stack pointer will have (which can depending on the direction the stack grows be different). This difference makes the `makecontext' function hard to use and it requires detection of the platform at compile time. - Function: int setcontext (const ucontext_t *UCP) The `setcontext' function restores the context described by UCP. The context is not modified and can be reused as often as wanted. If the context was created by `getcontext' execution resumes with the registers filled with the same values and the same stack as if the `getcontext' call just returned. If the context was modified with a call to `makecontext' execution continues with the function passed to `makecontext' which gets the specified parameters passed. If this function returns execution is resumed in the context which was referenced by the `uc_link' element of the context structure passed to `makecontext' at the time of the call. If `uc_link' was a null pointer the application terminates in this case. Since the context contains information about the stack no two threads should use the same context at the same time. The result in most cases would be disastrous. The `setcontext' function does not return unless an error occurred in which case it returns `-1'. The `setcontext' function simply replaces the current context with the one described by the UCP parameter. This is often useful but there are situations where the current context has to be preserved. - Function: int swapcontext (ucontext_t *restrict OUCP, const ucontext_t *restrict UCP) The `swapcontext' function is similar to `setcontext' but instead of just replacing the current context the latter is first saved in the object pointed to by OUCP as if this was a call to `getcontext'. The saved context would resume after the call to `swapcontext'. Once the current context is saved the context described in UCP is installed and execution continues as described in this context. If `swapcontext' succeeds the function does not return unless the context OUCP is used without prior modification by `makecontext'. The return value in this case is `0'. If the function fails it returns `-1' and set ERRNO accordingly. Example for SVID Context Handling ================================= The easiest way to use the context handling functions is as a replacement for `setjmp' and `longjmp'. The context contains on most platforms more information which might lead to less surprises but this also means using these functions is more expensive (beside being less portable). int random_search (int n, int (*fp) (int, ucontext_t *)) { volatile int cnt = 0; ucontext_t uc; /* Safe current context. */ if (getcontext (&uc) < 0) return -1; /* If we have not tried N times try again. */ if (cnt++ < n) /* Call the function with a new random number and the context. */ if (fp (rand (), &uc) != 0) /* We found what we were looking for. */ return 1; /* Not found. */ return 0; } Using contexts in such a way enables emulating exception handling. The search functions passed in the FP parameter could be very large, nested, and complex which would make it complicated (or at least would require a lot of code) to leave the function with an error value which has to be passed down to the caller. By using the context it is possible to leave the search function in one step and allow restarting the search which also has the nice side effect that it can be significantly faster. Something which is harder to implement with `setjmp' and `longjmp' is to switch temporarily to a different execution path and then resume where execution was stopped. #include #include #include #include #include /* Set by the signal handler. */ static volatile int expired; /* The contexts. */ static ucontext_t uc[3]; /* We do only a certain number of switches. */ static int switches; /* This is the function doing the work. It is just a skeleton, real code has to be filled in. */ static void f (int n) { int m = 0; while (1) { /* This is where the work would be done. */ if (++m % 100 == 0) { putchar ('.'); fflush (stdout); } /* Regularly the EXPIRE variable must be checked. */ if (expired) { /* We do not want the program to run forever. */ if (++switches == 20) return; printf ("\nswitching from %d to %d\n", n, 3 - n); expired = 0; /* Switch to the other context, saving the current one. */ swapcontext (&uc[n], &uc[3 - n]); } } } /* This is the signal handler which simply set the variable. */ void handler (int signal) { expired = 1; } int main (void) { struct sigaction sa; struct itimerval it; char st1[8192]; char st2[8192]; /* Initialize the data structures for the interval timer. */ sa.sa_flags = SA_RESTART; sigfillset (&sa.sa_mask); sa.sa_handler = handler; it.it_interval.tv_sec = 0; it.it_interval.tv_usec = 1; it.it_value = it.it_interval; /* Install the timer and get the context we can manipulate. */ if (sigaction (SIGPROF, &sa, NULL) < 0 || setitimer (ITIMER_PROF, &it, NULL) < 0 || getcontext (&uc[1]) == -1 || getcontext (&uc[2]) == -1) abort (); /* Create a context with a separate stack which causes the function `f' to be call with the parameter `1'. Note that the `uc_link' points to the main context which will cause the program to terminate once the function return. */ uc[1].uc_link = &uc[0]; uc[1].uc_stack.ss_sp = st1; uc[1].uc_stack.ss_size = sizeof st1; makecontext (&uc[1], (void (*) (void)) f, 1, 1); /* Similarly, but `2' is passed as the parameter to `f'. */ uc[2].uc_link = &uc[0]; uc[2].uc_stack.ss_sp = st2; uc[2].uc_stack.ss_size = sizeof st2; makecontext (&uc[2], (void (*) (void)) f, 1, 2); /* Start running. */ swapcontext (&uc[0], &uc[1]); putchar ('\n'); return 0; } This an example how the context functions can be used to implement co-routines or cooperative multi-threading. All that has to be done is to call every once in a while `swapcontext' to continue running a different context. It is not allowed to do the context switching from the signal handler directly since neither `setcontext' nor `swapcontext' are functions which can be called from a signal handler. But setting a variable in the signal handler and checking it in the body of the functions which are executed. Since `swapcontext' is saving the current context it is possible to have multiple different scheduling points in the code. Execution will always resume where it was left.  File: libc.info, Node: Signal Handling, Next: Program Basics, Prev: Non-Local Exits, Up: Top Signal Handling *************** A "signal" is a software interrupt delivered to a process. The operating system uses signals to report exceptional situations to an executing program. Some signals report errors such as references to invalid memory addresses; others report asynchronous events, such as disconnection of a phone line. The GNU C library defines a variety of signal types, each for a particular kind of event. Some kinds of events make it inadvisable or impossible for the program to proceed as usual, and the corresponding signals normally abort the program. Other kinds of signals that report harmless events are ignored by default. If you anticipate an event that causes signals, you can define a handler function and tell the operating system to run it when that particular type of signal arrives. Finally, one process can send a signal to another process; this allows a parent process to abort a child, or two related processes to communicate and synchronize. * Menu: * Concepts of Signals:: Introduction to the signal facilities. * Standard Signals:: Particular kinds of signals with standard names and meanings. * Signal Actions:: Specifying what happens when a particular signal is delivered. * Defining Handlers:: How to write a signal handler function. * Interrupted Primitives:: Signal handlers affect use of `open', `read', `write' and other functions. * Generating Signals:: How to send a signal to a process. * Blocking Signals:: Making the system hold signals temporarily. * Waiting for a Signal:: Suspending your program until a signal arrives. * Signal Stack:: Using a Separate Signal Stack. * BSD Signal Handling:: Additional functions for backward compatibility with BSD.  File: libc.info, Node: Concepts of Signals, Next: Standard Signals, Up: Signal Handling Basic Concepts of Signals ========================= This section explains basic concepts of how signals are generated, what happens after a signal is delivered, and how programs can handle signals. * Menu: * Kinds of Signals:: Some examples of what can cause a signal. * Signal Generation:: Concepts of why and how signals occur. * Delivery of Signal:: Concepts of what a signal does to the process.  File: libc.info, Node: Kinds of Signals, Next: Signal Generation, Up: Concepts of Signals Some Kinds of Signals --------------------- A signal reports the occurrence of an exceptional event. These are some of the events that can cause (or "generate", or "raise") a signal: * A program error such as dividing by zero or issuing an address outside the valid range. * A user request to interrupt or terminate the program. Most environments are set up to let a user suspend the program by typing `C-z', or terminate it with `C-c'. Whatever key sequence is used, the operating system sends the proper signal to interrupt the process. * The termination of a child process. * Expiration of a timer or alarm. * A call to `kill' or `raise' by the same process. * A call to `kill' from another process. Signals are a limited but useful form of interprocess communication. * An attempt to perform an I/O operation that cannot be done. Examples are reading from a pipe that has no writer (*note Pipes and FIFOs::), and reading or writing to a terminal in certain situations (*note Job Control::). Each of these kinds of events (excepting explicit calls to `kill' and `raise') generates its own particular kind of signal. The various kinds of signals are listed and described in detail in *Note Standard Signals::.  File: libc.info, Node: Signal Generation, Next: Delivery of Signal, Prev: Kinds of Signals, Up: Concepts of Signals Concepts of Signal Generation ----------------------------- In general, the events that generate signals fall into three major categories: errors, external events, and explicit requests. An error means that a program has done something invalid and cannot continue execution. But not all kinds of errors generate signals--in fact, most do not. For example, opening a nonexistent file is an error, but it does not raise a signal; instead, `open' returns `-1'. In general, errors that are necessarily associated with certain library functions are reported by returning a value that indicates an error. The errors which raise signals are those which can happen anywhere in the program, not just in library calls. These include division by zero and invalid memory addresses. An external event generally has to do with I/O or other processes. These include the arrival of input, the expiration of a timer, and the termination of a child process. An explicit request means the use of a library function such as `kill' whose purpose is specifically to generate a signal. Signals may be generated "synchronously" or "asynchronously". A synchronous signal pertains to a specific action in the program, and is delivered (unless blocked) during that action. Most errors generate signals synchronously, and so do explicit requests by a process to generate a signal for that same process. On some machines, certain kinds of hardware errors (usually floating-point exceptions) are not reported completely synchronously, but may arrive a few instructions later. Asynchronous signals are generated by events outside the control of the process that receives them. These signals arrive at unpredictable times during execution. External events generate signals asynchronously, and so do explicit requests that apply to some other process. A given type of signal is either typically synchronous or typically asynchronous. For example, signals for errors are typically synchronous because errors generate signals synchronously. But any type of signal can be generated synchronously or asynchronously with an explicit request.  File: libc.info, Node: Delivery of Signal, Prev: Signal Generation, Up: Concepts of Signals How Signals Are Delivered ------------------------- When a signal is generated, it becomes "pending". Normally it remains pending for just a short period of time and then is "delivered" to the process that was signaled. However, if that kind of signal is currently "blocked", it may remain pending indefinitely--until signals of that kind are "unblocked". Once unblocked, it will be delivered immediately. *Note Blocking Signals::. When the signal is delivered, whether right away or after a long delay, the "specified action" for that signal is taken. For certain signals, such as `SIGKILL' and `SIGSTOP', the action is fixed, but for most signals, the program has a choice: ignore the signal, specify a "handler function", or accept the "default action" for that kind of signal. The program specifies its choice using functions such as `signal' or `sigaction' (*note Signal Actions::). We sometimes say that a handler "catches" the signal. While the handler is running, that particular signal is normally blocked. If the specified action for a kind of signal is to ignore it, then any such signal which is generated is discarded immediately. This happens even if the signal is also blocked at the time. A signal discarded in this way will never be delivered, not even if the program subsequently specifies a different action for that kind of signal and then unblocks it. If a signal arrives which the program has neither handled nor ignored, its "default action" takes place. Each kind of signal has its own default action, documented below (*note Standard Signals::). For most kinds of signals, the default action is to terminate the process. For certain kinds of signals that represent "harmless" events, the default action is to do nothing. When a signal terminates a process, its parent process can determine the cause of termination by examining the termination status code reported by the `wait' or `waitpid' functions. (This is discussed in more detail in *Note Process Completion::.) The information it can get includes the fact that termination was due to a signal and the kind of signal involved. If a program you run from a shell is terminated by a signal, the shell typically prints some kind of error message. The signals that normally represent program errors have a special property: when one of these signals terminates the process, it also writes a "core dump file" which records the state of the process at the time of termination. You can examine the core dump with a debugger to investigate what caused the error. If you raise a "program error" signal by explicit request, and this terminates the process, it makes a core dump file just as if the signal had been due directly to an error.  File: libc.info, Node: Standard Signals, Next: Signal Actions, Prev: Concepts of Signals, Up: Signal Handling Standard Signals ================ This section lists the names for various standard kinds of signals and describes what kind of event they mean. Each signal name is a macro which stands for a positive integer--the "signal number" for that kind of signal. Your programs should never make assumptions about the numeric code for a particular kind of signal, but rather refer to them always by the names defined here. This is because the number for a given kind of signal can vary from system to system, but the meanings of the names are standardized and fairly uniform. The signal names are defined in the header file `signal.h'. - Macro: int NSIG The value of this symbolic constant is the total number of signals defined. Since the signal numbers are allocated consecutively, `NSIG' is also one greater than the largest defined signal number. * Menu: * Program Error Signals:: Used to report serious program errors. * Termination Signals:: Used to interrupt and/or terminate the program. * Alarm Signals:: Used to indicate expiration of timers. * Asynchronous I/O Signals:: Used to indicate input is available. * Job Control Signals:: Signals used to support job control. * Operation Error Signals:: Used to report operational system errors. * Miscellaneous Signals:: Miscellaneous Signals. * Signal Messages:: Printing a message describing a signal.  File: libc.info, Node: Program Error Signals, Next: Termination Signals, Up: Standard Signals Program Error Signals --------------------- The following signals are generated when a serious program error is detected by the operating system or the computer itself. In general, all of these signals are indications that your program is seriously broken in some way, and there's usually no way to continue the computation which encountered the error. Some programs handle program error signals in order to tidy up before terminating; for example, programs that turn off echoing of terminal input should handle program error signals in order to turn echoing back on. The handler should end by specifying the default action for the signal that happened and then reraising it; this will cause the program to terminate with that signal, as if it had not had a handler. (*Note Termination in Handler::.) Termination is the sensible ultimate outcome from a program error in most programs. However, programming systems such as Lisp that can load compiled user programs might need to keep executing even if a user program incurs an error. These programs have handlers which use `longjmp' to return control to the command level. The default action for all of these signals is to cause the process to terminate. If you block or ignore these signals or establish handlers for them that return normally, your program will probably break horribly when such signals happen, unless they are generated by `raise' or `kill' instead of a real error. When one of these program error signals terminates a process, it also writes a "core dump file" which records the state of the process at the time of termination. The core dump file is named `core' and is written in whichever directory is current in the process at the time. (On the GNU system, you can specify the file name for core dumps with the environment variable `COREFILE'.) The purpose of core dump files is so that you can examine them with a debugger to investigate what caused the error. - Macro: int SIGFPE The `SIGFPE' signal reports a fatal arithmetic error. Although the name is derived from "floating-point exception", this signal actually covers all arithmetic errors, including division by zero and overflow. If a program stores integer data in a location which is then used in a floating-point operation, this often causes an "invalid operation" exception, because the processor cannot recognize the data as a floating-point number. Actual floating-point exceptions are a complicated subject because there are many types of exceptions with subtly different meanings, and the `SIGFPE' signal doesn't distinguish between them. The `IEEE Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Std 754-1985 and ANSI/IEEE Std 854-1987)' defines various floating-point exceptions and requires conforming computer systems to report their occurrences. However, this standard does not specify how the exceptions are reported, or what kinds of handling and control the operating system can offer to the programmer. BSD systems provide the `SIGFPE' handler with an extra argument that distinguishes various causes of the exception. In order to access this argument, you must define the handler to accept two arguments, which means you must cast it to a one-argument function type in order to establish the handler. The GNU library does provide this extra argument, but the value is meaningful only on operating systems that provide the information (BSD systems and GNU systems). `FPE_INTOVF_TRAP' Integer overflow (impossible in a C program unless you enable overflow trapping in a hardware-specific fashion). `FPE_INTDIV_TRAP' Integer division by zero. `FPE_SUBRNG_TRAP' Subscript-range (something that C programs never check for). `FPE_FLTOVF_TRAP' Floating overflow trap. `FPE_FLTDIV_TRAP' Floating/decimal division by zero. `FPE_FLTUND_TRAP' Floating underflow trap. (Trapping on floating underflow is not normally enabled.) `FPE_DECOVF_TRAP' Decimal overflow trap. (Only a few machines have decimal arithmetic and C never uses it.) - Macro: int SIGILL The name of this signal is derived from "illegal instruction"; it usually means your program is trying to execute garbage or a privileged instruction. Since the C compiler generates only valid instructions, `SIGILL' typically indicates that the executable file is corrupted, or that you are trying to execute data. Some common ways of getting into the latter situation are by passing an invalid object where a pointer to a function was expected, or by writing past the end of an automatic array (or similar problems with pointers to automatic variables) and corrupting other data on the stack such as the return address of a stack frame. `SIGILL' can also be generated when the stack overflows, or when the system has trouble running the handler for a signal. - Macro: int SIGSEGV This signal is generated when a program tries to read or write outside the memory that is allocated for it, or to write memory that can only be read. (Actually, the signals only occur when the program goes far enough outside to be detected by the system's memory protection mechanism.) The name is an abbreviation for "segmentation violation". Common ways of getting a `SIGSEGV' condition include dereferencing a null or uninitialized pointer, or when you use a pointer to step through an array, but fail to check for the end of the array. It varies among systems whether dereferencing a null pointer generates `SIGSEGV' or `SIGBUS'. - Macro: int SIGBUS This signal is generated when an invalid pointer is dereferenced. Like `SIGSEGV', this signal is typically the result of dereferencing an uninitialized pointer. The difference between the two is that `SIGSEGV' indicates an invalid access to valid memory, while `SIGBUS' indicates an access to an invalid address. In particular, `SIGBUS' signals often result from dereferencing a misaligned pointer, such as referring to a four-word integer at an address not divisible by four. (Each kind of computer has its own requirements for address alignment.) The name of this signal is an abbreviation for "bus error". - Macro: int SIGABRT This signal indicates an error detected by the program itself and reported by calling `abort'. *Note Aborting a Program::. - Macro: int SIGIOT Generated by the PDP-11 "iot" instruction. On most machines, this is just another name for `SIGABRT'. - Macro: int SIGTRAP Generated by the machine's breakpoint instruction, and possibly other trap instructions. This signal is used by debuggers. Your program will probably only see `SIGTRAP' if it is somehow executing bad instructions. - Macro: int SIGEMT Emulator trap; this results from certain unimplemented instructions which might be emulated in software, or the operating system's failure to properly emulate them. - Macro: int SIGSYS Bad system call; that is to say, the instruction to trap to the operating system was executed, but the code number for the system call to perform was invalid.  File: libc.info, Node: Termination Signals, Next: Alarm Signals, Prev: Program Error Signals, Up: Standard Signals Termination Signals ------------------- These signals are all used to tell a process to terminate, in one way or another. They have different names because they're used for slightly different purposes, and programs might want to handle them differently. The reason for handling these signals is usually so your program can tidy up as appropriate before actually terminating. For example, you might want to save state information, delete temporary files, or restore the previous terminal modes. Such a handler should end by specifying the default action for the signal that happened and then reraising it; this will cause the program to terminate with that signal, as if it had not had a handler. (*Note Termination in Handler::.) The (obvious) default action for all of these signals is to cause the process to terminate. - Macro: int SIGTERM The `SIGTERM' signal is a generic signal used to cause program termination. Unlike `SIGKILL', this signal can be blocked, handled, and ignored. It is the normal way to politely ask a program to terminate. The shell command `kill' generates `SIGTERM' by default. - Macro: int SIGINT The `SIGINT' ("program interrupt") signal is sent when the user types the INTR character (normally `C-c'). *Note Special Characters::, for information about terminal driver support for `C-c'. - Macro: int SIGQUIT The `SIGQUIT' signal is similar to `SIGINT', except that it's controlled by a different key--the QUIT character, usually `C-\'--and produces a core dump when it terminates the process, just like a program error signal. You can think of this as a program error condition "detected" by the user. *Note Program Error Signals::, for information about core dumps. *Note Special Characters::, for information about terminal driver support. Certain kinds of cleanups are best omitted in handling `SIGQUIT'. For example, if the program creates temporary files, it should handle the other termination requests by deleting the temporary files. But it is better for `SIGQUIT' not to delete them, so that the user can examine them in conjunction with the core dump. - Macro: int SIGKILL The `SIGKILL' signal is used to cause immediate program termination. It cannot be handled or ignored, and is therefore always fatal. It is also not possible to block this signal. This signal is usually generated only by explicit request. Since it cannot be handled, you should generate it only as a last resort, after first trying a less drastic method such as `C-c' or `SIGTERM'. If a process does not respond to any other termination signals, sending it a `SIGKILL' signal will almost always cause it to go away. In fact, if `SIGKILL' fails to terminate a process, that by itself constitutes an operating system bug which you should report. The system will generate `SIGKILL' for a process itself under some unusual conditions where the program cannot possibly continue to run (even to run a signal handler). - Macro: int SIGHUP The `SIGHUP' ("hang-up") signal is used to report that the user's terminal is disconnected, perhaps because a network or telephone connection was broken. For more information about this, see *Note Control Modes::. This signal is also used to report the termination of the controlling process on a terminal to jobs associated with that session; this termination effectively disconnects all processes in the session from the controlling terminal. For more information, see *Note Termination Internals::.  File: libc.info, Node: Alarm Signals, Next: Asynchronous I/O Signals, Prev: Termination Signals, Up: Standard Signals Alarm Signals ------------- These signals are used to indicate the expiration of timers. *Note Setting an Alarm::, for information about functions that cause these signals to be sent. The default behavior for these signals is to cause program termination. This default is rarely useful, but no other default would be useful; most of the ways of using these signals would require handler functions in any case. - Macro: int SIGALRM This signal typically indicates expiration of a timer that measures real or clock time. It is used by the `alarm' function, for example. - Macro: int SIGVTALRM This signal typically indicates expiration of a timer that measures CPU time used by the current process. The name is an abbreviation for "virtual time alarm". - Macro: int SIGPROF This signal typically indicates expiration of a timer that measures both CPU time used by the current process, and CPU time expended on behalf of the process by the system. Such a timer is used to implement code profiling facilities, hence the name of this signal.  File: libc.info, Node: Asynchronous I/O Signals, Next: Job Control Signals, Prev: Alarm Signals, Up: Standard Signals Asynchronous I/O Signals ------------------------ The signals listed in this section are used in conjunction with asynchronous I/O facilities. You have to take explicit action by calling `fcntl' to enable a particular file descriptor to generate these signals (*note Interrupt Input::). The default action for these signals is to ignore them. - Macro: int SIGIO This signal is sent when a file descriptor is ready to perform input or output. On most operating systems, terminals and sockets are the only kinds of files that can generate `SIGIO'; other kinds, including ordinary files, never generate `SIGIO' even if you ask them to. In the GNU system `SIGIO' will always be generated properly if you successfully set asynchronous mode with `fcntl'. - Macro: int SIGURG This signal is sent when "urgent" or out-of-band data arrives on a socket. *Note Out-of-Band Data::. - Macro: int SIGPOLL This is a System V signal name, more or less similar to `SIGIO'. It is defined only for compatibility.