Changed all @example to @smallexample; misc changes for formatting.
[kopensolaris-gnu/glibc.git] / manual / intro.texi
1 @node Introduction, Error Reporting, Top, Top
2 @chapter Introduction
3
4 The C language provides no built-in facilities for performing such
5 common operations as input/output, memory management, string
6 manipulation, and the like.  Instead, these facilities are defined
7 in a standard @dfn{library}, which you compile and link with your
8 programs.
9 @cindex library
10
11 The GNU C library, described in this document, defines all of the
12 library functions that are specified by the ANSI C standard, as well as
13 additional features specific to POSIX and other derivatives of the Unix
14 operating system, and extensions specific to the GNU system.
15
16 The purpose of this manual is to tell you how to use the facilities
17 of the GNU library.  We have mentioned which features belong to which
18 standards to help you identify things that are potentially nonportable
19 to other systems.  But the emphasis on this manual is not on strict
20 portability.
21
22 @menu
23 * Getting Started::             What this manual is for and how to use it.
24 * Standards and Portability::   Standards and sources upon which the GNU
25                                  C library is based.
26 * Using the Library::           Some practical uses for the library.
27 * Roadmap to the Manual::       Overview of the remaining chapters in
28                                  this manual.
29 @end menu
30
31 @node Getting Started, Standards and Portability,  , Introduction
32 @section Getting Started
33
34 This manual is written with the assumption that you are at least
35 somewhat familiar with the C programming language and basic programming
36 concepts.  Specifically, familiarity with ANSI standard C
37 (@pxref{ANSI C}), rather than ``traditional'' pre-ANSI C dialects, is
38 assumed.
39
40 The GNU C library includes several @dfn{header files}, each of which
41 provides definitions and declarations for a group of related facilities;
42 this information is used by the C compiler when processing your program.
43 For example, the header file @file{stdio.h} declares facilities for
44 performing input and output, and the header file @file{string.h}
45 declares string processing utilities.  The organization of this manual
46 generally follows the same division as the header files.
47
48 If you are reading this manual for the first time, you should read all
49 of the introductory material and skim the remaining chapters.  There are
50 a @emph{lot} of functions in the GNU C library and it's not realistic to
51 expect that you will be able to remember exactly @emph{how} to use each
52 and every one of them.  It's more important to become generally familiar
53 with the kinds of facilities that the library provides, so that when you
54 are writing your programs you can recognize @emph{when} to make use of
55 library functions, and @emph{where} in this manual you can find more
56 specific information about them.
57
58
59 @node Standards and Portability, Using the Library, Getting Started, Introduction
60 @section Standards and Portability
61 @cindex standards
62
63 This section discusses the various standards and other sources that the
64 GNU C library is based upon.  These sources include the ANSI C and
65 POSIX standards, and the System V and Berkeley Unix implementations.
66
67 The primary focus of this manual is to tell you how to make effective
68 use of the GNU library facilities.  But if you are concerned about
69 making your programs compatible with these standards, or portable to
70 operating systems other than GNU, this can affect how you use the
71 library.  This section gives you an overview of these standards, so that
72 you will know what they are when they are mentioned in other parts of
73 the manual.
74
75 @xref{Library Summary}, for an alphabetical list of the functions and
76 other symbols provided by the library.  This list also states which
77 standards each function or symbol comes from.
78
79 @menu
80 * ANSI C::                      The American National Standard for the
81                                  C programming language.  
82 * POSIX::                       The IEEE 1003 standards for operating
83                                  systems. 
84 * Berkeley Unix::               BSD and SunOS.
85 * SVID::                        The System V Interface Description.  
86 @end menu
87
88 @node ANSI C, POSIX,  , Standards and Portability
89 @subsection ANSI C
90 @cindex ANSI C
91
92 The GNU C library is compatible with the C standard adopted by the
93 American National Standards Institute (ANSI):
94 @cite{American National Standard X3.159-1989---``ANSI C''}.
95 The header files and library facilities that make up the GNU library are
96 a superset of those specified by the ANSI C standard.@refill
97
98 @pindex gcc
99 If you are concerned about strict adherence to the ANSI C standard, you
100 should use the @samp{-ansi} option when you compile your programs with
101 the GNU C compiler.  This tells the compiler to define @emph{only} ANSI
102 standard features from the library header files, unless you explicitly
103 ask for additional features.  @xref{Feature Test Macros}, for
104 information on how to do this.
105
106 Being able to restrict the library to include only ANSI C features is
107 important because ANSI C puts limitations on what names can be defined
108 by the library implementation, and the GNU extensions don't fit these
109 limitations.  @xref{Reserved Names}, for more information about these
110 restrictions.
111
112 This manual does not attempt to give you complete details on the
113 differences between ANSI C and older dialects.  It gives advice on how
114 to write programs to work portably under multiple C dialects, but does
115 not aim for completeness.
116
117 @node POSIX, Berkeley Unix, ANSI C, Standards and Portability
118 @subsection @sc{posix} (The Portable Operating System Interface)
119 @cindex POSIX
120 @cindex POSIX.1
121 @cindex IEEE Std 1003.1
122 @cindex POSIX.2
123 @cindex IEEE Std 1003.2
124
125 The GNU library is also compatible with the IEEE @dfn{POSIX} family of
126 standards, known more formally as the @dfn{Portable Operating System
127 Interface for Computer Environments}.  POSIX is derived mostly from
128 various versions of the Unix operating system.
129
130 The library facilities specified by the POSIX standard are a superset of
131 those required by ANSI C; POSIX specifies additional features for ANSI C
132 functions, as well as specifying new additional functions.  In general,
133 the additional requirements and functionality defined by the POSIX
134 standard are aimed at providing lower-level support for a particular
135 kind of operating system environment, rather than general programming
136 language support which can run in many diverse operating system
137 environments.@refill
138
139 The GNU C library implements all of the functions specified in
140 @cite{IEEE Std 1003.1-1988, the POSIX System Application Program
141 Interface}, commonly referred to as POSIX.1.  The primary extensions to
142 the ANSI C facilities specified by this standard include file system
143 interface primitives (@pxref{File System Interface}), device-specific
144 terminal control functions (@pxref{Low-Level Terminal Interface}), and
145 process control functions (@pxref{Child Processes}).
146
147 Some facilities from draft 11 of @cite{IEEE Std 1003.2, the POSIX Shell
148 and Utilities standard} (POSIX.2) are also implemented in the GNU
149 library.  These include utilities for dealing with regular expressions
150 and other pattern matching facilities (@pxref{Pattern Matching}).
151
152 @comment Roland sez:
153 @comment The GNU C library as it stands conforms to 1003.2 draft 11, which
154 @comment specifies:
155 @comment 
156 @comment Several new macros in <limits.h>.
157 @comment popen, pclose
158 @comment <regex.h> (which is not yet fully implemented--wait on this)
159 @comment fnmatch
160 @comment getopt
161 @comment <glob.h>
162 @comment <wordexp.h> (not yet implemented)
163 @comment confstr
164
165
166 @node Berkeley Unix, SVID, POSIX, Standards and Portability
167 @subsection Berkeley Unix
168 @cindex BSD Unix
169 @cindex 4.x BSD Unix
170 @cindex Berkeley Unix
171 @cindex SunOS
172 @cindex Unix, Berkeley
173
174 The GNU C library defines facilities from some other versions of Unix,
175 specifically from the 4.2 BSD and 4.3 BSD Unix systems (also known as
176 @dfn{Berkeley Unix}) and from @dfn{SunOS} (a popular 4.2 BSD derivative
177 that includes some Unix System V functionality).  
178
179 The BSD facilities include symbolic links (@pxref{Symbolic Links}), the
180 @code{select} function (@pxref{Waiting for I/O}), the BSD signal
181 functions (@pxref{BSD Signal Handling}), and sockets (@pxref{Sockets}).
182
183 @node SVID,  , Berkeley Unix, Standards and Portability
184 @subsection @sc{svid} (The System V Interface Description)
185 @cindex SVID
186 @cindex System V Unix
187 @cindex Unix, System V
188
189 The @dfn{System V Interface Description} (SVID) is a document describing
190 the AT&T Unix System V operating system.  It is to some extent a
191 superset of the POSIX standard (@pxref{POSIX}).
192
193 The GNU C library defines some of the facilities required by the SVID
194 that are not also required by the ANSI or POSIX standards, for
195 compatibility with  System V Unix and other Unix systems (such as
196 SunOS) which include these facilities.  However, many of the more
197 obscure and less generally useful facilities required by the SVID are
198 not included.  (In fact, Unix System V itself does not provide them all.)
199
200 @strong{Incomplete:}  Are there any particular System V facilities that
201 ought to be mentioned specifically here?
202
203
204
205 @node Using the Library, Roadmap to the Manual, Standards and Portability, Introduction
206 @section Using the Library
207
208 This section describes some of the practical issues involved in using
209 the GNU C library.
210
211 @menu
212 * Header Files::                How to include the header files in your
213                                  programs. 
214 * Macro Definitions::           Some functions in the library may really
215                                  be implemented as macros.
216 * Reserved Names::              The C standard reserves some names for
217                                  the library, and some for users.
218 * Feature Test Macros::         How to control what names are defined.
219 @end menu
220
221 @node Header Files, Macro Definitions,  , Using the Library
222 @subsection Header Files
223 @cindex header files
224
225 Libraries for use by C programs really consist of two parts: @dfn{header
226 files} that define types and macros and declare variables and
227 functions; and the actual library or @dfn{archive} that contains the
228 definitions of the variables and functions.
229
230 (Recall that in C, a @dfn{declaration} merely provides information that
231 a function or variable exists and gives its type.  For a function
232 declaration, information about the types of its arguments might be
233 provided as well.  The purpose of declarations is to allow the compiler
234 to correctly process references to the declared variables and functions.
235 A @dfn{definition}, on the other hand, actually allocates storage for a
236 variable or says what a function does.)
237 @cindex definition (compared to declaration)
238 @cindex declaration (compared to definition)
239
240 In order to use the facilities in the GNU C library, you should be sure
241 that your program source files include the appropriate header files.
242 This is so that the compiler has declarations of these facilities
243 available and can correctly process references to them.  Once your
244 program has been compiled, the linker resolves these references to
245 the actual definitions provided in the archive file.
246
247 Header files are included into a program source file by the
248 @samp{#include} preprocessor directive.  The C language supports two
249 forms of this directive; the first,
250
251 @smallexample
252 #include "@var{header}"
253 @end smallexample
254
255 @noindent
256 is typically used to include a header file @var{header} that you write
257 yourself; this would contain definitions and declarations describing the
258 interfaces between the different parts of your particular application.
259 By contrast,
260
261 @smallexample
262 #include <file.h>
263 @end smallexample
264
265 @noindent
266 is typically used to include a header file @file{file.h} that contains
267 definitions and declarations for a standard library.  This file would
268 normally be installed in a standard place by your system administrator.
269 You should use this second form for the C library header files.
270
271 Typically, @samp{#include} directives are placed at the top of the C
272 source file, before any other code.  If you begin your source files with
273 some comments explaining what the code in the file does (a good idea),
274 put the @samp{#include} directives immediately afterwards, following the
275 feature test macro definition (@pxref{Feature Test Macros}).
276
277 For more information about the use of header files and @samp{#include}
278 directives, @pxref{Header Files,,, cpp.info, The GNU C Preprocessor
279 Manual}.@refill
280
281 The GNU C library provides several header files, each of which contains
282 the type and macro definitions and variable and function declarations
283 for a group of related facilities.  This means that your programs may
284 need to include several header files, depending on exactly which
285 facilities you are using.
286
287 Some library header files include other library header files
288 automatically.  However, as a matter of programming style, you should
289 not rely on this; it is better to explicitly include all the header
290 files required for the library facilities you are using.  The GNU C
291 library header files have been written in such a way that it doesn't
292 matter if a header file is accidentally included more than once;
293 including a header file a second time has no effect.  Likewise, if your
294 program needs to include multiple header files, the order in which they
295 are included doesn't matter.
296
297 @strong{Compatibility Note:} Inclusion of standard header files in any
298 order and any number of times works in any ANSI C implementation.
299 However, this has traditionally not been the case in many older C
300 implementations.
301
302 Strictly speaking, you don't @emph{have to} include a header file to use
303 a function it declares; you could declare the function explicitly
304 yourself, according to the specifications in this manual.  But it is
305 usually better to include the header file because it may define types
306 and macros that are not otherwise available and because it may define
307 more efficient macro replacements for some functions.  It is also a sure
308 way to have the correct declaration.
309
310 @node Macro Definitions, Reserved Names, Header Files, Using the Library
311 @subsection Macro Definitions of Functions
312 @cindex shadowing functions with macros
313 @cindex removing macros that shadow functions
314 @cindex undefining macros that shadow functions
315
316 If we describe something as a function in this manual, it may have a
317 macro definition as well.  This normally has no effect on how your
318 program runs---the macro definition does the same thing as the function
319 would.  In particular, macro equivalents for library functions evaluate
320 arguments exactly once, in the same way that a function call would.  The
321 main reason for these macro definitions is that sometimes they can
322 produce an inline expansion that is considerably faster than an actual
323 function call.
324
325 Taking the address of a library function works even if it is also
326 defined as a macro.  This is because, in this context, the name of the
327 function isn't followed by the left parenthesis that is syntactically
328 necessary to recognize the  a macro call.
329
330 You might occasionally want to avoid using the a macro definition of a
331 function---perhaps to make your program easier to debug.  There are
332 two ways you can do this:
333
334 @itemize @bullet
335 @item 
336 You can avoid a macro definition in a specific use by enclosing the name
337 of the function in parentheses.  This works because the name of the
338 function doesn't appear in a syntactic context where it is recognizable
339 as a macro call.
340
341 @item
342 You can suppress any macro definition for a whole source file by using
343 the @samp{#undef} preprocessor directive, unless otherwise stated
344 explicitly in the description of that facility.
345 @end itemize
346
347 For example, suppose the header file @file{stdlib.h} declares a function
348 named @code{abs} with
349
350 @smallexample
351 extern int abs (int);
352 @end smallexample
353
354 @noindent
355 and also provides a macro definition for @code{abs}.  Then, in:
356
357 @smallexample
358 #include <stdlib.h>
359 int f (int *i) @{ return (abs (++*i)); @}
360 @end smallexample
361
362 @noindent
363 the reference to @code{abs} might refer to either a macro or a function.
364 On the other hand, in each of the following examples the reference is
365 to a function and not a macro.
366
367 @smallexample
368 #include <stdlib.h>
369 int g (int *i) @{ return ((abs)(++*i)); @}
370
371 #undef abs
372 int h (int *i) @{ return (abs (++*i)); @}
373 @end smallexample
374
375 Since macro definitions that double for a function behave in
376 exactly the same way as the actual function version, there is usually no
377 need for any of these methods.  In fact, removing macro definitions usually
378 just makes your program slower.
379
380
381 @node Reserved Names, Feature Test Macros, Macro Definitions, Using the Library
382 @subsection Reserved Names
383 @cindex reserved names
384 @cindex name space
385
386 The names of all library types, macros, variables and functions that
387 come from the ANSI C standard are reserved unconditionally; your program
388 @strong{may not} redefine these names.  All other library names are
389 reserved if your programs explicitly includes the header file that
390 defines or declares them.  There are several reasons for these
391 restrictions:
392
393 @itemize @bullet
394 @item
395 Other people reading your code could get very confused if you were using
396 a function named @code{exit} to do something completely different from
397 what the standard @code{exit} function does, for example.  Preventing
398 this situation helps to make your programs easier to understand and
399 contributes to modularity and maintainability.
400
401 @item
402 It avoids the possibility of a user accidentally redefining a library
403 function that is called by other library functions.  If redefinition
404 were allowed, those other functions would not work properly.
405
406 @item
407 It allows the compiler to do whatever special optimizations it pleases
408 on calls to these functions, without the possibility that they may have
409 been redefined by the user.  Some library facilities, such as those for
410 dealing with variadic arguments (@pxref{Variadic Functions})
411 and non-local exits (@pxref{Non-Local Exits}), actually require a
412 considerable amount of cooperation on the part of the C compiler, and
413 implementationally it might be easier for the compiler to treat these as
414 built-in parts of the language.
415 @end itemize
416
417 In addition to the names documented in this manual, reserved names
418 include all external identifiers (global functions and variables) that
419 begin with an underscore (@samp{_}) and all identifiers regardless of
420 use that begin with either two underscores or an underscore followed by
421 a capital letter are reserved names.  This is so that the library and
422 header files can define functions, variables, and macros for internal
423 purposes without risk of conflict with names in user programs.
424
425 Some additional classes of identifier names are reserved for future
426 extensions to the C language.  While using these names for your own
427 purposes right now might not cause a problem, they do raise the
428 possibility of conflict with future versions of the C standard, so you
429 should avoid these names.
430
431 @itemize @bullet
432 @item 
433 Names beginning with a capital @samp{E} followed a digit or uppercase
434 letter may be used for additional error code names.  @xref{Error
435 Reporting}.
436
437 @item
438 Names that begin with either @samp{is} or @samp{to} followed by a
439 lowercase letter may be used for additional character testing and
440 conversion functions.  @xref{Character Handling}.
441
442 @item
443 Names that begin with @samp{LC_} followed by an uppercase letter may be
444 used for additional macros specifying locale attributes.
445 @xref{Locales}.
446
447 @item
448 Names of all existing mathematics functions (@pxref{Mathematics})
449 suffixed with @samp{f} or @samp{l} are reserved for corresponding
450 functions that operate on @code{float} or @code{long double} arguments,
451 respectively.
452
453 @item
454 Names that begin with @samp{SIG} followed by an uppercase letter are
455 reserved for additional signal names.  @xref{Standard Signals}.
456
457 @item
458 Names that begin with @samp{SIG_} followed by an uppercase letter are
459 reserved for additional signal actions.  @xref{Basic Signal Handling}.
460
461 @item
462 Names beginning with @samp{str}, @samp{mem}, or @samp{wcs} followed by a
463 lowercase letter are reserved for additional string and array functions.
464 @xref{String and Array Utilities}.
465
466 @item
467 Names that end with @samp{_t} are reserved for additional type names.
468 @end itemize
469
470 In addition, some individual header files reserve names beyond
471 those that they actually define.  You only need to worry about these
472 restrictions if your program includes that particular header file.
473
474 @itemize @bullet
475 @item
476 The header file @file{dirent.h} reserves names prefixed with
477 @samp{d_}.
478 @pindex dirent.h
479
480 @item
481 The header file @file{fcntl.h} reserves names prefixed with
482 @samp{l_}, @samp{F_}, @samp{O_}, and @samp{S_}.
483 @pindex fcntl.h
484
485 @item
486 The header file @file{grp.h} reserves names prefixed with @samp{gr_}.
487 @pindex grp.h
488
489 @item
490 The header file @file{limits.h} reserves names suffixed with @samp{_MAX}.
491 @pindex limits.h
492
493 @item
494 The header file @file{pwd.h} reserves names prefixed with @samp{pw_}.
495 @pindex pwd.h
496
497 @item
498 The header file @file{signal.h} reserves names prefixed with @samp{sa_}
499 and @samp{SA_}.
500 @pindex signal.h
501
502 @item
503 The header file @file{sys/stat.h} reserves names prefixed with @samp{st_}
504 and @samp{S_}.
505 @pindex sys/stat.h
506
507 @item
508 The header file @file{sys/times.h} reserves names prefixed with @samp{tms_}.
509 @pindex sys/times.h
510
511 @item
512 The header file @file{termios.h} reserves names prefixed with @samp{c_},
513 @samp{V}, @samp{I}, @samp{O}, and @samp{TC}; and names prefixed with
514 @samp{B} followed by a digit.
515 @pindex termios.h
516 @end itemize
517
518
519 @node Feature Test Macros,  , Reserved Names, Using the Library
520 @subsection Feature Test Macros
521
522 @cindex feature test macros
523 The exact set of features available when you compile a source file
524 is controlled by which @dfn{feature test macros} you define.
525
526 If you compile your programs using @samp{gcc -ansi}, you get only the
527 ANSI C library features, unless you explicitly request additional
528 features by defining one or more of the feature macros.
529 @xref{Invoking GCC,, GNU CC Command Options, gcc.info, The GNU CC Manual},
530 for more information about GCC options.@refill
531
532 You should define these macros by using @samp{#define} preprocessor
533 directives at the top of your source code files.  You could also use 
534 the @samp{-D} option to GCC, but it's better if you make the source
535 files indicate their own meaning in a self-contained way.
536
537 @comment (none)
538 @comment POSIX.1
539 @defvr Macro _POSIX_SOURCE
540 If you define this macro, then the functionality from the POSIX.1
541 standard (IEEE Standard 1003.1) is available, as well as all of the
542 ANSI C facilities.
543 @end defvr
544
545 @comment (none)
546 @comment POSIX.2
547 @defvr Macro _POSIX_C_SOURCE
548 If you define this macro with a value of @code{1}, then the
549 functionality from the POSIX.1 standard (IEEE Standard 1003.1) is made
550 available.  If you define this macro with a value of @code{2}, then both
551 the functionality from the POSIX.1 standard and the functionality from
552 the POSIX.2 standard (IEEE Standard 1003.2) are made available.  This is
553 in addition to the ANSI C facilities.
554 @end defvr
555
556 @comment (none)
557 @comment GNU
558 @defvr Macro _BSD_SOURCE
559 If you define this macro, functionality derived from 4.3 BSD Unix is
560 included as well as the ANSI C, POSIX.1, and POSIX.2 material.
561
562 Some of the features derived from 4.3 BSD Unix conflict with the
563 corresponding features specified by the POSIX.1 standard.  If this
564 macro is defined, the 4.3 BSD definitions take precedence over the
565 POSIX definitions.
566
567 Due to the nature of some of the conflicts between 4.3 BSD and POSIX.1,
568 you need to use a special @dfn{BSD compatibility library} when linking
569 programs compiled for BSD compatibility.  This is because some functions
570 must be defined in two different ways, one of them in the normal C
571 library, and one of them in the compatibility library.  If your program
572 defines @code{_BSD_SOURCE}, you must give the option @samp{-lbsd-compat}
573 to the compiler or linker when linking the program, to tell it to find
574 functions in this special compatibility library before looking for them in
575 the normal C library.
576 @pindex -lbsd-compat
577 @pindex bsd-compat
578 @cindex BSD compatibility library.
579 @end defvr
580
581 @comment (none)
582 @comment GNU
583 @defvr Macro _SVID_SOURCE
584 If you define this macro, functionality derived from SVID is
585 included as well as the ANSI C, POSIX.1, and POSIX.2 material.
586 @end defvr
587
588 @comment (none)
589 @comment GNU
590 @defvr Macro _GNU_SOURCE
591 If you define this macro, everything is included: ANSI C, POSIX.1,
592 POSIX.2, BSD, SVID, and GNU extensions.  In the cases where POSIX.1
593 conflicts with BSD, the POSIX definitions take precedence.
594
595 If you want to get the full effect of @code{_GNU_SOURCE} but make the
596 BSD definitions take precedence over the POSIX definitions, use this
597 sequence of definitions:
598
599 @smallexample
600 #define _GNU_SOURCE
601 #define _BSD_SOURCE
602 #define _SVID_SOURCE
603 @end smallexample
604
605 Note that if you do this, you may need to link your program with the BSD
606 compatibility library by passing the @samp{-lbsd-compat} option to the
607 compiler or linker.
608 @end defvr
609
610 We recommend you use @code{_GNU_SOURCE} in new programs.
611 If you don't specify the @samp{-ansi} option to GCC and don't define
612 any of these macros explicitly, the effect as the same as defining
613 @code{_GNU_SOURCE}.
614
615 When you define a feature test macro to request a larger class of
616 features, it is harmless to define in addition a feature test macro for
617 a subset of those features.  For example, if you define
618 @code{_POSIX_C_SOURCE}, then defining @code{_POSIX_SOURCE} as well has
619 no effect.  Likewise, if you define @code{_GNU_SOURCE}, then defining
620 either @code{_POSIX_SOURCE} or @code{_POSIX_C_SOURCE} or
621 @code{_SVID_SOURCE} as well has no effect.
622
623 Note, however, that the features of @code{_BSD_SOURCE} are not a subset
624 of any of the other feature test macros supported.  This is because it
625 defines BSD features that take precedence over the POSIX features that
626 are requested by the other macros.  For this reason, defining
627 @code{_BSD_SOURCE} in addition to the other feature test macros does
628 have an effect: it causes the BSD features to take priority over the
629 conflicting POSIX features.
630
631 @node Roadmap to the Manual,  , Using the Library, Introduction
632 @section Roadmap to the Manual
633
634 Here is an overview of the contents of the remaining chapters of
635 this manual.
636
637 @itemize @bullet
638 @item 
639 @ref{Error Reporting}, describes how errors detected by the library
640 are reported.
641
642 @item 
643 @ref{Language Features}, contains information about library support for
644 standard parts of the C language, including things like the
645 @code{sizeof} operator and the symbolic constant @code{NULL}, and how to
646 write functions accepting variable numbers of arguments.
647
648 @item 
649 @ref{Memory Allocation}, describes the GNU library's facilities for
650 dynamic allocation of storage.  If you do not know in advance how much
651 storage your program needs, you can allocate it dynamically instead,
652 and manipulate it via pointers.
653
654 @item 
655 @ref{Character Handling}, contains information about character
656 classification functions (such as @code{isspace}) and functions for
657 performing case conversion.
658
659 @item 
660 @ref{String and Array Utilities}, has descriptions of functions for
661 manipulating strings (null-terminated character arrays) and general
662 byte arrays, including operations such as copying and comparison.
663
664 @item 
665 @ref{Extended Characters}, contains information about manipulating
666 characters and strings using character sets larger than will fit in
667 the usual @code{char} data type.  
668
669 @item 
670 @ref{Locales}, describes how selecting a particular country 
671 or language affects the behavior of the library.  For example, the locale
672 affects collation sequences for strings and how monetary values are
673 formatted.
674
675 @item 
676 @ref{Searching and Sorting}, contains information about functions
677 for searching and sorting arrays.  You can use these functions on any
678 kind of array by providing an appropriate comparison function.
679
680 @item
681 @ref{I/O Overview}, gives an overall look at the input and output
682 facilities in the library, and contains information about basic concepts
683 such as file names.
684
685 @item
686 @ref{I/O on Streams}, describes I/O operations involving streams (or
687 @w{@code{FILE *}} objects).  These are the normal C library functions
688 from @file{stdio.h}.
689
690 @item
691 @ref{Low-Level I/O}, contains information about I/O operations
692 on file descriptors.  File descriptors are a lower-level mechanism
693 specific to the Unix family of operating systems.
694
695 @item
696 @ref{File System Interface}, has descriptions of operations on entire
697 files, such as functions for deleting and renaming them and for creating
698 new directories.  This chapter also contains information about how you
699 can access the attributes of a file, such as its owner and file protection
700 modes.
701
702 @item
703 @ref{Pipes and FIFOs}, contains information about simple interprocess
704 communication mechanisms.  Pipes allow communication between two related
705 processes (such as between a parent and child), while FIFOs allow
706 communication between processes sharing a common file system.
707
708 @item
709 @ref{Sockets}, describes a more complicated interprocess communication
710 mechanism that allows processes running on different machines to
711 communicate over a network.  This chapter also contains information about
712 Internet host addressing and how to use the system network databases,
713 such as @file{/etc/hosts}.
714
715 @item
716 @ref{Low-Level Terminal Interface}, describes how you can change the
717 attributes of a terminal device.  If you want to disable echo of
718 characters typed by the user, for example, read this chapter.
719
720 @item 
721 @ref{Consistency Checking}, contains information about a simple
722 debugging mechanism.  You can put assertions in your code, and
723 diagnostic messages are printed if the test fails.
724
725 @item 
726 @ref{Mathematics}, contains information about the math library
727 functions.  These include things like random-number generators and
728 remainder functions on integers as well as the usual trigonometric and
729 exponential functions on floating-point numbers.
730
731 @item
732 @ref{Date and Time}, describes functions for measuring both calendar time
733 and CPU time, as well as functions for setting alarms and timers.
734
735 @item
736 @ref{Non-Local Exits}, contains descriptions of the @code{setjmp} and
737 @code{longjmp} functions.
738
739 @item
740 @ref{Signal Handling}, tells you all about signals---what they are,
741 how to establish a handler that is called when a particular kind of
742 signal is delivered, and how to prevent signals from arriving during
743 critical sections of your program.
744
745 @item 
746 @ref{Child Processes}, contains information about how to start new processes
747 and run programs.
748
749 @item
750 @ref{Process Startup}, tells how your programs can access their
751 command-line arguments and environment variables.
752
753 @item
754 @ref{Job Control}, describes functions for manipulating process groups.
755 This material is probably only of interest if you are writing a shell.
756
757 @item
758 @ref{User Database}, and @ref{Group Database}, tell you how to access
759 the system user and group databases.
760
761 @item
762 @ref{System Information}, describes functions for getting information
763 about the hardware and software configuration your program is executing
764 under.
765
766 @item 
767 @ref{Range of Type}, contains information about
768 parameters that characterize the sizes of integer and floating-point
769 types used by the particular C implementation that your program has
770 been compiled with.  Most of these parameters are provided for 
771 compatibility with ANSI C.
772
773 @item 
774 @ref{System Configuration}, tells you how you can get
775 information about various operating system limits.  Most of these
776 parameters are provided for compatibility with POSIX.
777 @end itemize
778
779 If you already know the name of the facility you are interested in, you
780 can look it up in @ref{Library Summary}.  This gives you a summary of
781 its syntax and a pointer to where you can find a more detailed
782 description.  This appendix is particularly useful if you just want to
783 verify the order and type of arguments to a function, for example.