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