glibc/manual/lang.texi

@node Language Features, Library Summary, System Configuration, Top
@appendix C Language Facilities in the Library

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

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

@node Consistency Checking
@section Explicitly Checking Internal Consistency
@cindex consistency checking
@cindex impossible events
@cindex assertions

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

@pindex assert.h
The @code{assert} macro, defined in the header file @file{assert.h},
provides a convenient way to abort the program while printing a message
about where in the program the error was detected.

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

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

@comment assert.h
@comment ANSI
@deftypefn Macro void assert (int @var{expression})
Verify the programmer's belief that @var{expression} should be nonzero
at this point in the program.

If @code{NDEBUG} is not defined, @code{assert} tests the value of
@var{expression}.  If it is false (zero), @code{assert} aborts the
program (@pxref{Aborting a Program}) after printing a message of the
form:

@smallexample
@file{@var{file}}:@var{linenum}: Assertion `@var{expression}' failed.
@end smallexample

@noindent
on the standard error stream @code{stderr} (@pxref{Standard Streams}).
The filename and line number are taken from the C preprocessor macros
@code{__FILE__} and @code{__LINE__} and specify where the call to
@code{assert} was written.

If the preprocessor macro @code{NDEBUG} is defined at the point where
@file{assert.h} is included, the @code{assert} macro is defined to do
absolutely nothing.

@strong{Warning:} Even the argument expression @var{expression} is not
evaluated if @code{NDEBUG} is in effect.  So never use @code{assert}
with arguments that involve side effects.  For example, @code{assert
(++i > 0);} is a bad idea, because @code{i} will not be incremented if
@code{NDEBUG} is defined.
@end deftypefn

@strong{Usage note:} The @code{assert} facility is designed for
detecting @emph{internal inconsistency}; it is not suitable for
reporting invalid input or improper usage by @emph{the user} of the
program.

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

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

@xref{Error Messages}, for information on printing error messages for
problems that @emph{do not} represent bugs in the program.


@node Variadic Functions
@section Variadic Functions
@cindex variable number of arguments
@cindex variadic functions
@cindex optional arguments

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

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

@strong{Compatibility Note:} Many older C dialects provide a similar,
but incompatible, mechanism for defining functions with variable numbers
of arguments, using @file{varargs.h}.

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

@node Why Variadic
@subsection Why Variadic Functions are Used

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

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

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

The library function @code{printf} (@pxref{Formatted Output}) is an
example of another class of function where variable arguments are
useful.  This function prints its arguments (which can vary in type as
well as number) under the control of a format template string.

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

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

@node How Variadic
@subsection How Variadic Functions are Defined and Used

Defining and using a variadic function involves three steps:

@itemize @bullet
@item
@emph{Define} the function as variadic, using an ellipsis
(@samp{@dots{}}) in the argument list, and using special macros to
access the variable arguments.  @xref{Receiving Arguments}.

@item
@emph{Declare} the function as variadic, using a prototype with an
ellipsis (@samp{@dots{}}), in all the files which call it.
@xref{Variadic Prototypes}.

@item
@emph{Call} the function by writing the fixed arguments followed by the
additional variable arguments.  @xref{Calling Variadics}.
@end itemize

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

@node Variadic Prototypes
@subsubsection Syntax for Variable Arguments
@cindex function prototypes (variadic)
@cindex prototypes for variadic functions
@cindex variadic function prototypes

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

@smallexample
int 
func (const char *a, int b, @dots{})
@{
  @dots{}
@}	
@end smallexample

@noindent
outlines a definition of a function @code{func} which returns an
@code{int} and takes two required arguments, a @code{const char *} and
an @code{int}.  These are followed by any number of anonymous
arguments.

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

@node Receiving Arguments
@subsubsection Receiving the Argument Values
@cindex variadic function argument access
@cindex arguments (variadic functions)

Ordinary fixed arguments have individual names, and you can use these
names to access their values.  But optional arguments have no
names---nothing but @samp{@dots{}}.  How can you access them?

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

@enumerate
@item
You initialize an argument pointer variable of type @code{va_list} using
@code{va_start}.  The argument pointer when initialized points to the
first optional argument.

@item
You access the optional arguments by successive calls to @code{va_arg}.
The first call to @code{va_arg} gives you the first optional argument,
the next call gives you the second, and so on.

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

@item
You indicate that you are finished with the argument pointer variable by
calling @code{va_end}.

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

@xref{Argument Macros}, for the full definitions of @code{va_start}, 
@code{va_arg} and @code{va_end}.

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

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

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

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

@node How Many Arguments
@subsubsection How Many Arguments Were Supplied
@cindex number of arguments passed
@cindex how many arguments
@cindex arguments, how many

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

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

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

A required argument can be used as a pattern to specify both the number
and types of the optional arguments.  The format string argument to
@code{printf} is one example of this (@pxref{Formatted Output Functions}).

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


@node Calling Variadics
@subsubsection Calling Variadic Functions
@cindex variadic functions, calling
@cindex calling variadic functions
@cindex declaring variadic functions

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

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

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

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

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

@node Argument Macros
@subsubsection Argument Access Macros

Here are descriptions of the macros used to retrieve variable arguments.
These macros are defined in the header file @file{stdarg.h}.
@pindex stdarg.h

@comment stdarg.h
@comment ANSI
@deftp {Data Type} va_list
The type @code{va_list} is used for argument pointer variables.
@end deftp

@comment stdarg.h
@comment ANSI
@deftypefn {Macro} void va_start (va_list @var{ap}, @var{last-required})
This macro initializes the argument pointer variable @var{ap} to point
to the first of the optional arguments of the current function;
@var{last-required} must be the last required argument to the function.

@xref{Old Varargs}, for an alternate definition of @code{va_start}
found in the header file @file{varargs.h}.
@end deftypefn

@comment stdarg.h
@comment ANSI
@deftypefn {Macro} @var{type} va_arg (va_list @var{ap}, @var{type})
The @code{va_arg} macro returns the value of the next optional argument,
and modifies the value of @var{ap} to point to the subsequent argument.
Thus, successive uses of @code{va_arg} return successive optional 
arguments.

The type of the value returned by @code{va_arg} is @var{type} as
specified in the call.  @var{type} must be a self-promoting type (not
@code{char} or @code{short int} or @code{float}) that matches the type
of the actual argument.
@end deftypefn

@comment stdarg.h
@comment ANSI
@deftypefn {Macro} void va_end (va_list @var{ap})
This ends the use of @var{ap}.  After a @code{va_end} call, further
@code{va_arg} calls with the same @var{ap} may not work.  You should invoke
@code{va_end} before returning from the function in which @code{va_start}
was invoked with the same @var{ap} argument.

In the GNU C library, @code{va_end} does nothing, and you need not ever
use it except for reasons of portability.
@refill
@end deftypefn

@node Variadic Example
@subsection Example of a Variadic Function

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

@comment Yes, this example has been tested.
@smallexample
@include add.c.texi
@end smallexample

@node Old Varargs
@subsubsection Old-Style Variadic Functions

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

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

@smallexample
tree
build (va_alist)
     va_dcl
@{
@end smallexample

Secondly, you must give @code{va_start} just one argument, like this:

@smallexample
  va_list p;
  va_start (p);
@end smallexample

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

@comment varargs.h
@comment Unix
@deffn Macro va_alist
This macro stands for the argument name list required in a variadic
function.  
@end deffn

@comment varargs.h
@comment Unix
@deffn Macro va_dcl
This macro declares the implicit argument or arguments for a variadic
function.
@end deffn

@comment varargs.h
@comment Unix
@deftypefn {Macro} void va_start (va_list @var{ap})
This macro, as defined in @file{varargs.h}, initializes the argument
pointer variable @var{ap} to point to the first argument of the current
function.
@end deftypefn

The other argument macros, @code{va_arg} and @code{va_end}, are the same
in @file{varargs.h} as in @file{stdarg.h}; see @ref{Argument Macros} for
details.

It does not work to include both @file{varargs.h} and @file{stdarg.h} in
the same compilation; they define @code{va_start} in conflicting ways.

@node Null Pointer Constant
@section Null Pointer Constant
@cindex null pointer constant

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

@comment stddef.h
@comment ANSI
@deftypevr Macro {void *} NULL
This is a null pointer constant.
@end deftypevr

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

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

@node Important Data Types
@section Important Data Types

The result of subtracting two pointers in C is always an integer, but the
precise data type varies from C compiler to C compiler.  Likewise, the
data type of the result of @code{sizeof} also varies between compilers.
ANSI defines standard aliases for these two types, so you can refer to
them in a portable fashion.  They are defined in the header file 
@file{stddef.h}.
@pindex stddef.h

@comment stddef.h
@comment ANSI
@deftp {Data Type} ptrdiff_t
This is the signed integer type of the result of subtracting two
pointers.  For example, with the declaration @code{char *p1, *p2;}, the
expression @code{p2 - p1} is of type @code{ptrdiff_t}.  This will
probably be one of the standard signed integer types (@w{@code{short
int}}, @code{int} or @w{@code{long int}}), but might be a nonstandard
type that exists only for this purpose.
@end deftp

@comment stddef.h
@comment ANSI
@deftp {Data Type} size_t
This is an unsigned integer type used to represent the sizes of objects.
The result of the @code{sizeof} operator is of this type, and functions
such as @code{malloc} (@pxref{Unconstrained Allocation}) and
@code{memcpy} (@pxref{Copying and Concatenation}) accept arguments of
this type to specify object sizes.

@strong{Usage Note:} @code{size_t} is the preferred way to declare any
arguments or variables that hold the size of an object.
@end deftp

In the GNU system @code{size_t} is equivalent to either
@w{@code{unsigned int}} or @w{@code{unsigned long int}}.  These types
have identical properties on the GNU system, and for most purposes, you
can use them interchangeably.  However, they are distinct as data types,
which makes a difference in certain contexts.

For example, when you specify the type of a function argument in a
function prototype, it makes a difference which one you use.  If the
system header files declare @code{malloc} with an argument of type
@code{size_t} and you declare @code{malloc} with an argument of type
@code{unsigned int}, you will get a compilation error if @code{size_t}
happens to be @code{unsigned long int} on your system.  To avoid any
possibility of error, when a function argument or value is supposed to
have type @code{size_t}, never declare its type in any other way.

@strong{Compatibility Note:} Implementations of C before the advent of
ANSI C generally used @code{unsigned int} for representing object sizes
and @code{int} for pointer subtraction results.  They did not
necessarily define either @code{size_t} or @code{ptrdiff_t}.  Unix
systems did define @code{size_t}, in @file{sys/types.h}, but the
definition was usually a signed type.

@node Data Type Measurements
@section Data Type Measurements

Most of the time, if you choose the proper C data type for each object
in your program, you need not be concerned with just how it is
represented or how many bits it uses.  When you do need such
information, the C language itself does not provide a way to get it.
The header files @file{limits.h} and @file{float.h} contain macros
which give you this information in full detail.

@menu
* Width of Type::           How many bits does an integer type hold?
* Range of Type::           What are the largest and smallest values
			     that an integer type can hold?
* Floating Type Macros::    Parameters that measure the floating point types. 
* Structure Measurement::   Getting measurements on structure types.
@end menu

@node Width of Type
@subsection Computing the Width of an Integer Data Type
@cindex integer type width
@cindex width of integer type
@cindex type measurements, integer

The most common reason that a program needs to know how many bits are in
an integer type is for using an array of @code{long int} as a bit vector.
You can access the bit at index @var{n} with

@smallexample
vector[@var{n} / LONGBITS] & (1 << (@var{n} % LONGBITS))
@end smallexample

@noindent
provided you define @code{LONGBITS} as the number of bits in a
@code{long int}.

@pindex limits.h
There is no operator in the C language that can give you the number of
bits in an integer data type.  But you can compute it from the macro
@code{CHAR_BIT}, defined in the header file @file{limits.h}.

@table @code
@comment limits.h
@comment ANSI
@item CHAR_BIT
This is the number of bits in a @code{char}---eight, on most systems.
The value has type @code{int}.

You can compute the number of bits in any data type @var{type} like
this:

@smallexample
sizeof (@var{type}) * CHAR_BIT
@end smallexample
@end table

@node Range of Type
@subsection Range of an Integer Type
@cindex integer type range
@cindex range of integer type
@cindex limits, integer types

Suppose you need to store an integer value which can range from zero to
one million.  Which is the smallest type you can use?  There is no
general rule; it depends on the C compiler and target machine.  You can
use the @samp{MIN} and @samp{MAX} macros in @file{limits.h} to determine
which type will work.

Each signed integer type has a pair of macros which give the smallest
and largest values that it can hold.  Each unsigned integer type has one
such macro, for the maximum value; the minimum value is, of course,
zero.

The values of these macros are all integer constant expressions.  The
@samp{MAX} and @samp{MIN} macros for @code{char} and @w{@code{short
int}} types have values of type @code{int}.  The @samp{MAX} and
@samp{MIN} macros for the other types have values of the same type
described by the macro---thus, @code{ULONG_MAX} has type
@w{@code{unsigned long int}}.

@comment Extra blank lines make it look better.
@table @code
@comment limits.h
@comment ANSI
@item SCHAR_MIN

This is the minimum value that can be represented by a @w{@code{signed char}}.

@comment limits.h
@comment ANSI
@item SCHAR_MAX
@comment limits.h
@comment ANSI
@itemx UCHAR_MAX

These are the maximum values that can be represented by a
@w{@code{signed char}} and @w{@code{unsigned char}}, respectively.

@comment limits.h
@comment ANSI
@item CHAR_MIN

This is the minimum value that can be represented by a @code{char}.
It's equal to @code{SCHAR_MIN} if @code{char} is signed, or zero
otherwise.

@comment limits.h
@comment ANSI
@item CHAR_MAX

This is the maximum value that can be represented by a @code{char}.
It's equal to @code{SCHAR_MAX} if @code{char} is signed, or
@code{UCHAR_MAX} otherwise.

@comment limits.h
@comment ANSI
@item SHRT_MIN

This is the minimum value that can be represented by a @w{@code{signed
short int}}.  On most machines that the GNU C library runs on,
@code{short} integers are 16-bit quantities.

@comment limits.h
@comment ANSI
@item SHRT_MAX
@comment limits.h
@comment ANSI
@itemx USHRT_MAX

These are the maximum values that can be represented by a
@w{@code{signed short int}} and @w{@code{unsigned short int}},
respectively.

@comment limits.h
@comment ANSI
@item INT_MIN

This is the minimum value that can be represented by a @w{@code{signed
int}}.  On most machines that the GNU C system runs on, an @code{int} is
a 32-bit quantity.

@comment limits.h
@comment ANSI
@item INT_MAX
@comment limits.h
@comment ANSI
@itemx UINT_MAX

These are the maximum values that can be represented by, respectively,
the type @w{@code{signed int}} and the type @w{@code{unsigned int}}.

@comment limits.h
@comment ANSI
@item LONG_MIN

This is the minimum value that can be represented by a @w{@code{signed
long int}}.  On most machines that the GNU C system runs on, @code{long}
integers are 32-bit quantities, the same size as @code{int}.

@comment limits.h
@comment ANSI
@item LONG_MAX
@comment limits.h
@comment ANSI
@itemx ULONG_MAX

These are the maximum values that can be represented by a
@w{@code{signed long int}} and @code{unsigned long int}, respectively.

@comment limits.h
@comment GNU
@item LONG_LONG_MIN

This is the minimum value that can be represented by a @w{@code{signed
long long int}}.  On most machines that the GNU C system runs on,
@w{@code{long long}} integers are 64-bit quantities.

@comment limits.h
@comment GNU
@item LONG_LONG_MAX
@comment limits.h
@comment ANSI
@itemx ULONG_LONG_MAX

These are the maximum values that can be represented by a @code{signed
long long int} and @code{unsigned long long int}, respectively.

@comment limits.h
@comment GNU
@item WCHAR_MAX

This is the maximum value that can be represented by a @code{wchar_t}.
@xref{Wide Char Intro}.
@end table

The header file @file{limits.h} also defines some additional constants
that parameterize various operating system and file system limits.  These
constants are described in @ref{System Configuration}.

@node Floating Type Macros
@subsection Floating Type Macros
@cindex floating type measurements
@cindex measurements of floating types
@cindex type measurements, floating
@cindex limits, floating types

The specific representation of floating point numbers varies from
machine to machine.  Because floating point numbers are represented
internally as approximate quantities, algorithms for manipulating
floating point data often need to take account of the precise details of
the machine's floating point representation.

Some of the functions in the C library itself need this information; for
example, the algorithms for printing and reading floating point numbers
(@pxref{I/O on Streams}) and for calculating trigonometric and
irrational functions (@pxref{Mathematics}) use it to avoid round-off
error and loss of accuracy.  User programs that implement numerical
analysis techniques also often need this information in order to
minimize or compute error bounds.

The header file @file{float.h} describes the format used by your
machine.

@menu
* Floating Point Concepts::     Definitions of terminology.
* Floating Point Parameters::   Details of specific macros.
* IEEE Floating Point::         The measurements for one common
                                 representation. 
@end menu

@node Floating Point Concepts
@subsubsection Floating Point Representation Concepts

This section introduces the terminology for describing floating point
representations.

You are probably already familiar with most of these concepts in terms
of scientific or exponential notation for floating point numbers.  For
example, the number @code{123456.0} could be expressed in exponential
notation as @code{1.23456e+05}, a shorthand notation indicating that the
mantissa @code{1.23456} is multiplied by the base @code{10} raised to
power @code{5}.

More formally, the internal representation of a floating point number
can be characterized in terms of the following parameters:

@itemize @bullet
@item
@cindex sign (of floating point number)
The @dfn{sign} is either @code{-1} or @code{1}.

@item
@cindex base (of floating point number)
@cindex radix (of floating point number)
The @dfn{base} or @dfn{radix} for exponentiation, an integer greater
than @code{1}.  This is a constant for a particular representation.

@item
@cindex exponent (of floating point number)
The @dfn{exponent} to which the base is raised.  The upper and lower
bounds of the exponent value are constants for a particular
representation.

@cindex bias (of floating point number exponent)
Sometimes, in the actual bits representing the floating point number,
the exponent is @dfn{biased} by adding a constant to it, to make it
always be represented as an unsigned quantity.  This is only important
if you have some reason to pick apart the bit fields making up the
floating point number by hand, which is something for which the GNU
library provides no support.  So this is ignored in the discussion that
follows.

@item
@cindex mantissa (of floating point number)
@cindex significand (of floating point number)
The @dfn{mantissa} or @dfn{significand}, an unsigned integer which is a
part of each floating point number.

@item 
@cindex precision (of floating point number)
The @dfn{precision} of the mantissa.  If the base of the representation
is @var{b}, then the precision is the number of base-@var{b} digits in
the mantissa.  This is a constant for a particular representation.

@cindex hidden bit (of floating point number mantissa)
Many floating point representations have an implicit @dfn{hidden bit} in
the mantissa.  This is a bit which is present virtually in the mantissa,
but not stored in memory because its value is always 1 in a normalized
number.  The precision figure (see above) includes any hidden bits.

Again, the GNU library provides no facilities for dealing with such
low-level aspects of the representation.
@end itemize

The mantissa of a floating point number actually represents an implicit
fraction whose denominator is the base raised to the power of the
precision.  Since the largest representable mantissa is one less than
this denominator, the value of the fraction is always strictly less than
@code{1}.  The mathematical value of a floating point number is then the
product of this fraction, the sign, and the base raised to the exponent.

@cindex normalized floating point number
We say that the floating point number is @dfn{normalized} if the
fraction is at least @code{1/@var{b}}, where @var{b} is the base.  In
other words, the mantissa would be too large to fit if it were
multiplied by the base.  Non-normalized numbers are sometimes called
@dfn{denormal}; they contain less precision than the representation
normally can hold.

If the number is not normalized, then you can subtract @code{1} from the
exponent while multiplying the mantissa by the base, and get another
floating point number with the same value.  @dfn{Normalization} consists
of doing this repeatedly until the number is normalized.  Two distinct
normalized floating point numbers cannot be equal in value.

(There is an exception to this rule: if the mantissa is zero, it is
considered normalized.  Another exception happens on certain machines
where the exponent is as small as the representation can hold.  Then
it is impossible to subtract @code{1} from the exponent, so a number
may be normalized even if its fraction is less than @code{1/@var{b}}.)

@node Floating Point Parameters
@subsubsection Floating Point Parameters

@pindex float.h
These macro definitions can be accessed by including the header file
@file{float.h} in your program.

Macro names starting with @samp{FLT_} refer to the @code{float} type,
while names beginning with @samp{DBL_} refer to the @code{double} type
and names beginning with @samp{LDBL_} refer to the @code{long double}
type.  (Currently GCC does not support @code{long double} as a distinct
data type, so the values for the @samp{LDBL_} constants are equal to the
corresponding constants for the @code{double} type.)@refill

Of these macros, only @code{FLT_RADIX} is guaranteed to be a constant
expression.  The other macros listed here cannot be reliably used in
places that require constant expressions, such as @samp{#if}
preprocessing directives or in the dimensions of static arrays.

Although the ANSI C standard specifies minimum and maximum values for
most of these parameters, the GNU C implementation uses whatever values
describe the floating point representation of the target machine.  So in
principle GNU C actually satisfies the ANSI C requirements only if the
target machine is suitable.  In practice, all the machines currently
supported are suitable.

@table @code
@comment float.h
@comment ANSI
@item FLT_ROUNDS
This value characterizes the rounding mode for floating point addition.
The following values indicate standard rounding modes:

@need 750

@table @code
@item -1
The mode is indeterminable.
@item 0
Rounding is towards zero.
@item 1
Rounding is to the nearest number.
@item 2
Rounding is towards positive infinity.
@item 3
Rounding is towards negative infinity.
@end table

@noindent
Any other value represents a machine-dependent nonstandard rounding
mode.

On most machines, the value is @code{1}, in accordance with the IEEE
standard for floating point.

Here is a table showing how certain values round for each possible value
of @code{FLT_ROUNDS}, if the other aspects of the representation match
the IEEE single-precision standard.

@smallexample
                0      1             2             3
 1.00000003    1.0    1.0           1.00000012    1.0
 1.00000007    1.0    1.00000012    1.00000012    1.0
-1.00000003   -1.0   -1.0          -1.0          -1.00000012
-1.00000007   -1.0   -1.00000012   -1.0          -1.00000012
@end smallexample

@comment float.h
@comment ANSI
@item FLT_RADIX
This is the value of the base, or radix, of exponent representation.
This is guaranteed to be a constant expression, unlike the other macros
described in this section.  The value is 2 on all machines we know of
except the IBM 360 and derivatives.

@comment float.h
@comment ANSI
@item FLT_MANT_DIG
This is the number of base-@code{FLT_RADIX} digits in the floating point
mantissa for the @code{float} data type.  The following expression
yields @code{1.0} (even though mathematically it should not) due to the
limited number of mantissa digits:

@smallexample
float radix = FLT_RADIX;

1.0f + 1.0f / radix / radix / @dots{} / radix
@end smallexample

@noindent
where @code{radix} appears @code{FLT_MANT_DIG} times.

@comment float.h
@comment ANSI
@item DBL_MANT_DIG
@itemx LDBL_MANT_DIG
This is the number of base-@code{FLT_RADIX} digits in the floating point
mantissa for the data types @code{double} and @code{long double},
respectively.

@comment Extra blank lines make it look better.
@comment float.h
@comment ANSI
@item FLT_DIG

This is the number of decimal digits of precision for the @code{float}
data type.  Technically, if @var{p} and @var{b} are the precision and
base (respectively) for the representation, then the decimal precision
@var{q} is the maximum number of decimal digits such that any floating
point number with @var{q} base 10 digits can be rounded to a floating
point number with @var{p} base @var{b} digits and back again, without
change to the @var{q} decimal digits.

The value of this macro is supposed to be at least @code{6}, to satisfy
ANSI C.

@comment float.h
@comment ANSI
@item DBL_DIG
@itemx LDBL_DIG

These are similar to @code{FLT_DIG}, but for the data types
@code{double} and @code{long double}, respectively.  The values of these
macros are supposed to be at least @code{10}.

@comment float.h
@comment ANSI
@item FLT_MIN_EXP
This is the smallest possible exponent value for type @code{float}.
More precisely, is the minimum negative integer such that the value
@code{FLT_RADIX} raised to this power minus 1 can be represented as a
normalized floating point number of type @code{float}.

@comment float.h
@comment ANSI
@item DBL_MIN_EXP
@itemx LDBL_MIN_EXP

These are similar to @code{FLT_MIN_EXP}, but for the data types
@code{double} and @code{long double}, respectively.

@comment float.h
@comment ANSI
@item FLT_MIN_10_EXP
This is the minimum negative integer such that @code{10} raised to this
power minus 1 can be represented as a normalized floating point number
of type @code{float}.  This is supposed to be @code{-37} or even less.

@comment float.h
@comment ANSI
@item DBL_MIN_10_EXP
@itemx LDBL_MIN_10_EXP
These are similar to @code{FLT_MIN_10_EXP}, but for the data types
@code{double} and @code{long double}, respectively.

@comment float.h
@comment ANSI
@item FLT_MAX_EXP
This is the largest possible exponent value for type @code{float}.  More
precisely, this is the maximum positive integer such that value
@code{FLT_RADIX} raised to this power minus 1 can be represented as a
floating point number of type @code{float}.

@comment float.h
@comment ANSI
@item DBL_MAX_EXP
@itemx LDBL_MAX_EXP
These are similar to @code{FLT_MAX_EXP}, but for the data types
@code{double} and @code{long double}, respectively.

@comment float.h
@comment ANSI
@item FLT_MAX_10_EXP
This is the maximum positive integer such that @code{10} raised to this
power minus 1 can be represented as a normalized floating point number
of type @code{float}.  This is supposed to be at least @code{37}.

@comment float.h
@comment ANSI
@item DBL_MAX_10_EXP
@itemx LDBL_MAX_10_EXP
These are similar to @code{FLT_MAX_10_EXP}, but for the data types
@code{double} and @code{long double}, respectively.

@comment float.h
@comment ANSI
@item FLT_MAX

The value of this macro is the maximum number representable in type
@code{float}.  It is supposed to be at least @code{1E+37}.  The value
has type @code{float}.

The smallest representable number is @code{- FLT_MAX}.

@comment float.h
@comment ANSI
@item DBL_MAX
@itemx LDBL_MAX

These are similar to @code{FLT_MAX}, but for the data types
@code{double} and @code{long double}, respectively.  The type of the
macro's value is the same as the type it describes.

@comment float.h
@comment ANSI
@item FLT_MIN

The value of this macro is the minimum normalized positive floating
point number that is representable in type @code{float}.  It is supposed
to be no more than @code{1E-37}.

@comment float.h
@comment ANSI
@item DBL_MIN
@itemx LDBL_MIN

These are similar to @code{FLT_MIN}, but for the data types
@code{double} and @code{long double}, respectively.  The type of the
macro's value is the same as the type it describes.

@comment float.h
@comment ANSI
@item FLT_EPSILON

This is the minimum positive floating point number of type @code{float}
such that @code{1.0 + FLT_EPSILON != 1.0} is true.  It's supposed to
be no greater than @code{1E-5}.

@comment float.h
@comment ANSI
@item DBL_EPSILON
@itemx LDBL_EPSILON

These are similar to @code{FLT_EPSILON}, but for the data types
@code{double} and @code{long double}, respectively.  The type of the
macro's value is the same as the type it describes.  The values are not
supposed to be greater than @code{1E-9}.
@end table

@node IEEE Floating Point
@subsubsection IEEE Floating Point
@cindex IEEE floating point representation 
@cindex floating point, IEEE

Here is an example showing how the floating type measurements come out
for the most common floating point representation, specified by the
@cite{IEEE Standard for Binary Floating Point Arithmetic (ANSI/IEEE Std
754-1985)}.  Nearly all computers designed since the 1980s use this
format.

The IEEE single-precision float representation uses a base of 2.  There
is a sign bit, a mantissa with 23 bits plus one hidden bit (so the total
precision is 24 base-2 digits), and an 8-bit exponent that can represent
values in the range -125 to 128, inclusive.

So, for an implementation that uses this representation for the
@code{float} data type, appropriate values for the corresponding
parameters are:

@smallexample
FLT_RADIX                             2
FLT_MANT_DIG                         24
FLT_DIG                               6
FLT_MIN_EXP                        -125
FLT_MIN_10_EXP                      -37
FLT_MAX_EXP                         128
FLT_MAX_10_EXP                      +38
FLT_MIN                 1.17549435E-38F
FLT_MAX                 3.40282347E+38F
FLT_EPSILON             1.19209290E-07F
@end smallexample

Here are the values for the @code{double} data type:

@smallexample
DBL_MANT_DIG                         53
DBL_DIG                              15
DBL_MIN_EXP                       -1021
DBL_MIN_10_EXP                     -307
DBL_MAX_EXP                        1024
DBL_MAX_10_EXP                      308
DBL_MAX         1.7976931348623157E+308
DBL_MIN         2.2250738585072014E-308
DBL_EPSILON     2.2204460492503131E-016
@end smallexample

@node Structure Measurement
@subsection Structure Field Offset Measurement

You can use @code{offsetof} to measure the location within a structure
type of a particular structure member.

@comment stddef.h
@comment ANSI
@deftypefn {Macro} size_t offsetof (@var{type}, @var{member})
This expands to a integer constant expression that is the offset of the
structure member named @var{member} in a the structure type @var{type}.
For example, @code{offsetof (struct s, elem)} is the offset, in bytes,
of the member @code{elem} in a @code{struct s}.

This macro won't work if @var{member} is a bit field; you get an error
from the C compiler in that case.
@end deftypefn