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

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

   This file documents the GNU C library.

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

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

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

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

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


File: libc.info,  Node: Non-Local Intro,  Next: Non-Local Details,  Up: Non-Local Exits

Introduction to Non-Local Exits
===============================

   As an example of a situation where a non-local exit can be useful,
suppose you have an interactive program that has a "main loop" that
prompts for and executes commands.  Suppose the "read" command reads
input from a file, doing some lexical analysis and parsing of the input
while processing it.  If a low-level input error is detected, it would
be useful to be able to return immediately to the "main loop" instead
of having to make each of the lexical analysis, parsing, and processing
phases all have to explicitly deal with error situations initially
detected by nested calls.

   (On the other hand, if each of these phases has to do a substantial
amount of cleanup when it exits--such as closing files, deallocating
buffers or other data structures, and the like--then it can be more
appropriate to do a normal return and have each phase do its own
cleanup, because a non-local exit would bypass the intervening phases
and their associated cleanup code entirely.  Alternatively, you could
use a non-local exit but do the cleanup explicitly either before or
after returning to the "main loop".)

   In some ways, a non-local exit is similar to using the `return'
statement to return from a function.  But while `return' abandons only
a single function call, transferring control back to the point at which
it was called, a non-local exit can potentially abandon many levels of
nested function calls.

   You identify return points for non-local exits calling the function
`setjmp'.  This function saves information about the execution
environment in which the call to `setjmp' appears in an object of type
`jmp_buf'.  Execution of the program continues normally after the call
to `setjmp', but if a exit is later made to this return point by
calling `longjmp' with the corresponding `jmp_buf' object, control is
transferred back to the point where `setjmp' was called.  The return
value from `setjmp' is used to distinguish between an ordinary return
and a return made by a call to `longjmp', so calls to `setjmp' usually
appear in an `if' statement.

   Here is how the example program described above might be set up:

     #include <setjmp.h>
     #include <stdlib.h>
     #include <stdio.h>
     
     jmp_buf main_loop;
     
     void
     abort_to_main_loop (int status)
     {
       longjmp (main_loop, status);
     }
     
     int
     main (void)
     {
       while (1)
         if (setjmp (main_loop))
           puts ("Back at main loop....");
         else
           do_command ();
     }
     
     
     void
     do_command (void)
     {
       char buffer[128];
       if (fgets (buffer, 128, stdin) == NULL)
         abort_to_main_loop (-1);
       else
         exit (EXIT_SUCCESS);
     }

   The function `abort_to_main_loop' causes an immediate transfer of
control back to the main loop of the program, no matter where it is
called from.

   The flow of control inside the `main' function may appear a little
mysterious at first, but it is actually a common idiom with `setjmp'.
A normal call to `setjmp' returns zero, so the "else" clause of the
conditional is executed.  If `abort_to_main_loop' is called somewhere
within the execution of `do_command', then it actually appears as if
the *same* call to `setjmp' in `main' were returning a second time with
a value of `-1'.

   So, the general pattern for using `setjmp' looks something like:

     if (setjmp (BUFFER))
       /* Code to clean up after premature return. */
       ...
     else
       /* Code to be executed normally after setting up the return point. */
       ...


File: libc.info,  Node: Non-Local Details,  Next: Non-Local Exits and Signals,  Prev: Non-Local Intro,  Up: Non-Local Exits

Details of Non-Local Exits
==========================

   Here are the details on the functions and data structures used for
performing non-local exits.  These facilities are declared in
`setjmp.h'.

 - Data Type: jmp_buf
     Objects of type `jmp_buf' hold the state information to be
     restored by a non-local exit.  The contents of a `jmp_buf'
     identify a specific place to return to.

 - Macro: int setjmp (jmp_buf STATE)
     When called normally, `setjmp' stores information about the
     execution state of the program in STATE and returns zero.  If
     `longjmp' is later used to perform a non-local exit to this STATE,
     `setjmp' returns a nonzero value.

 - Fonction: void longjmp (jmp_buf STATE, int VALUE)
     This function restores current execution to the state saved in
     STATE, and continues execution from the call to `setjmp' that
     established that return point.  Returning from `setjmp' by means of
     `longjmp' returns the VALUE argument that was passed to `longjmp',
     rather than `0'.  (But if VALUE is given as `0', `setjmp' returns
     `1').

   There are a lot of obscure but important restrictions on the use of
`setjmp' and `longjmp'.  Most of these restrictions are present because
non-local exits require a fair amount of magic on the part of the C
compiler and can interact with other parts of the language in strange
ways.

   The `setjmp' function is actually a macro without an actual function
definition, so you shouldn't try to `#undef' it or take its address.
In addition, calls to `setjmp' are safe in only the following contexts:

   * As the test expression of a selection or iteration statement (such
     as `if', `switch', or `while').

   * As one operand of a equality or comparison operator that appears
     as the test expression of a selection or iteration statement.  The
     other operand must be an integer constant expression.

   * As the operand of a unary `!' operator, that appears as the test
     expression of a selection or iteration statement.

   * By itself as an expression statement.

   Return points are valid only during the dynamic extent of the
function that called `setjmp' to establish them.  If you `longjmp' to a
return point that was established in a function that has already
returned, unpredictable and disastrous things are likely to happen.

   You should use a nonzero VALUE argument to `longjmp'.  While
`longjmp' refuses to pass back a zero argument as the return value from
`setjmp', this is intended as a safety net against accidental misuse
and is not really good programming style.

   When you perform a non-local exit, accessible objects generally
retain whatever values they had at the time `longjmp' was called.  The
exception is that the values of automatic variables local to the
function containing the `setjmp' call that have been changed since the
call to `setjmp' are indeterminate, unless you have declared them
`volatile'.


File: libc.info,  Node: Non-Local Exits and Signals,  Prev: Non-Local Details,  Up: Non-Local Exits

Non-Local Exits and Signals
===========================

   In BSD Unix systems, `setjmp' and `longjmp' also save and restore
the set of blocked signals; see *Note Blocking Signals::.  However, the
POSIX.1 standard requires `setjmp' and `longjmp' not to change the set
of blocked signals, and provides an additional pair of functions
(`sigsetjmp' and `sigsetjmp') to get the BSD behavior.

   The behavior of `setjmp' and `longjmp' in the GNU library is
controlled by feature test macros; see *Note Feature Test Macros::.  The
default in the GNU system is the POSIX.1 behavior rather than the BSD
behavior.

   The facilities in this section are declared in the header file
`setjmp.h'.

 - Data Type: sigjmp_buf
     This is similar to `jmp_buf', except that it can also store state
     information about the set of blocked signals.

 - Fonction: int sigsetjmp (sigjmp_buf STATE, int SAVESIGS)
     This is similar to `setjmp'.  If SAVESIGS is nonzero, the set of
     blocked signals is saved in STATE and will be restored if a
     `siglongjmp' is later performed with this STATE.

 - Fonction: void siglongjmp (sigjmp_buf STATE, int VALUE)
     This is similar to `longjmp' except for the type of its STATE
     argument.  If the `sigsetjmp' call that set this STATE used a
     nonzero SAVESIGS flag, `siglongjmp' also restores the set of
     blocked signals.


File: libc.info,  Node: Signal Handling,  Next: Process Startup,  Prev: Non-Local Exits,  Up: Top

Signal Handling
***************

   A "signal" is a software interrupt delivered to a process.  The
operating system uses signals to report exceptional situations to an
executing program.  Some signals report errors such as references to
invalid memory addresses; others report asynchronous events, such as
disconnection of a phone line.

   The GNU C library defines a variety of signal types, each for a
particular kind of event.  Some kinds of events make it inadvisable or
impossible for the program to proceed as usual, and the corresponding
signals normally abort the program.  Other kinds of signals that report
harmless events are ignored by default.

   If you anticipate an event that causes signals, you can define a
handler function and tell the operating system to run it when that
particular type of signal arrives.

   Finally, one process can send a signal to another process; this
allows a parent process to abort a child, or two related processes to
communicate and synchronize.

* Menü:

* Concepts of Signals::         Introduction to the signal facilities.
* Standard Signals::            Particular kinds of signals with
                                 standard names and meanings.
* Signal Actions::              Specifying what happens when a
                                 particular signal is delivered.
* Defining Handlers::           How to write a signal handler function.
* Interrupted Primitives::	Signal handlers affect use of `open',
				 `read', `write' and other functions.
* Generating Signals::          How to send a signal to a process.
* Blocking Signals::            Making the system hold signals temporarily.
* Waiting for a Signal::        Suspending your program until a signal
                                 arrives.
* Signal Stack::                Using a Separate Signal Stack.
* BSD Signal Handling::         Additional functions for backward
			         compatibility with BSD.


File: libc.info,  Node: Concepts of Signals,  Next: Standard Signals,  Up: Signal Handling

Basic Concepts of Signals
=========================

   This section explains basic concepts of how signals are generated,
what happens after a signal is delivered, and how programs can handle
signals.

* Menü:

* Kinds of Signals::            Some examples of what can cause a signal.
* Signal Generation::           Concepts of why and how signals occur.
* Delivery of Signal::          Concepts of what a signal does to the
                                 process.


File: libc.info,  Node: Kinds of Signals,  Next: Signal Generation,  Up: Concepts of Signals

Some Kinds of Signals
---------------------

   A signal reports the occurrence of an exceptional event.  These are
some of the events that can cause (or "generate", or "raise") a signal:

   * A program error such as dividing by zero or issuing an address
     outside the valid range.

   * A user request to interrupt or terminate the program.  Most
     environments are set up to let a user suspend the program by
     typing `C-z', or terminate it with `C-c'.  Whatever key sequence
     is used, the operating system sends the proper signal to interrupt
     the process.

   * The termination of a child process.

   * Expiration of a timer or alarm.

   * A call to `kill' or `raise' by the same process.

   * A call to `kill' from another process.  Signals are a limited but
     useful form of interprocess communication.

   * An attempt to perform an I/O operation that cannot be done.
     Examples are reading from a pipe that has no writer (*note Pipes
     and FIFOs::.), and reading or writing to a terminal in certain
     situations (*note Job Control::.).

   Each of these kinds of events (excepting explicit calls to `kill'
and `raise') generates its own particular kind of signal.  The various
kinds of signals are listed and described in detail in *Note Standard
Signals::.


File: libc.info,  Node: Signal Generation,  Next: Delivery of Signal,  Prev: Kinds of Signals,  Up: Concepts of Signals

Concepts of Signal Generation
-----------------------------

   In general, the events that generate signals fall into three major
categories: errors, external events, and explicit requests.

   An error means that a program has done something invalid and cannot
continue execution.  But not all kinds of errors generate signals--in
fact, most do not.  For example, opening a nonexistent file is an error,
but it does not raise a signal; instead, `open' returns `-1'.  In
general, errors that are necessarily associated with certain library
functions are reported by returning a value that indicates an error.
The errors which raise signals are those which can happen anywhere in
the program, not just in library calls.  These include division by zero
and invalid memory addresses.

   An external event generally has to do with I/O or other processes.
These include the arrival of input, the expiration of a timer, and the
termination of a child process.

   An explicit request means the use of a library function such as
`kill' whose purpose is specifically to generate a signal.

   Signals may be generated "synchronously" or "asynchronously".  A
synchronous signal pertains to a specific action in the program, and is
delivered (unless blocked) during that action.  Most errors generate
signals synchronously, and so do explicit requests by a process to
generate a signal for that same process.  On some machines, certain
kinds of hardware errors (usually floating-point exceptions) are not
reported completely synchronously, but may arrive a few instructions
later.

   Asynchronous signals are generated by events outside the control of
the process that receives them.  These signals arrive at unpredictable
times during execution.  External events generate signals
asynchronously, and so do explicit requests that apply to some other
process.

   A given type of signal is either typically synchronous or typically
asynchronous.  For example, signals for errors are typically synchronous
because errors generate signals synchronously.  But any type of signal
can be generated synchronously or asynchronously with an explicit
request.


File: libc.info,  Node: Delivery of Signal,  Prev: Signal Generation,  Up: Concepts of Signals

How Signals Are Delivered
-------------------------

   When a signal is generated, it becomes "pending".  Normally it
remains pending for just a short period of time and then is "delivered"
to the process that was signaled.  However, if that kind of signal is
currently "blocked", it may remain pending indefinitely--until signals
of that kind are "unblocked".  Once unblocked, it will be delivered
immediately.  *Note Blocking Signals::.

   When the signal is delivered, whether right away or after a long
delay, the "specified action" for that signal is taken.  For certain
signals, such as `SIGKILL' and `SIGSTOP', the action is fixed, but for
most signals, the program has a choice: ignore the signal, specify a
"handler function", or accept the "default action" for that kind of
signal.  The program specifies its choice using functions such as
`signal' or `sigaction' (*note Signal Actions::.).  We sometimes say
that a handler "catches" the signal.  While the handler is running,
that particular signal is normally blocked.

   If the specified action for a kind of signal is to ignore it, then
any such signal which is generated is discarded immediately.  This
happens even if the signal is also blocked at the time.  A signal
discarded in this way will never be delivered, not even if the program
subsequently specifies a different action for that kind of signal and
then unblocks it.

   If a signal arrives which the program has neither handled nor
ignored, its "default action" takes place.  Each kind of signal has its
own default action, documented below (*note Standard Signals::.).  For
most kinds of signals, the default action is to terminate the process.
For certain kinds of signals that represent "harmless" events, the
default action is to do nothing.

   When a signal terminates a process, its parent process can determine
the cause of termination by examining the termination status code
reported by the `wait' or `waitpid' functions.  (This is discussed in
more detail in *Note Process Completion::.)  The information it can get
includes the fact that termination was due to a signal, and the kind of
signal involved.  If a program you run from a shell is terminated by a
signal, the shell typically prints some kind of error message.

   The signals that normally represent program errors have a special
property: when one of these signals terminates the process, it also
writes a "core dump file" which records the state of the process at the
time of termination.  You can examine the core dump with a debugger to
investigate what caused the error.

   If you raise a "program error" signal by explicit request, and this
terminates the process, it makes a core dump file just as if the signal
had been due directly to an error.


File: libc.info,  Node: Standard Signals,  Next: Signal Actions,  Prev: Concepts of Signals,  Up: Signal Handling

Standard Signals
================

   This section lists the names for various standard kinds of signals
and describes what kind of event they mean.  Each signal name is a macro
which stands for a positive integer--the "signal number" for that kind
of signal.  Your programs should never make assumptions about the
numeric code for a particular kind of signal, but rather refer to them
always by the names defined here.  This is because the number for a
given kind of signal can vary from system to system, but the meanings of
the names are standardized and fairly uniform.

   The signal names are defined in the header file `signal.h'.

 - Macro: int NSIG
     The value of this symbolic constant is the total number of signals
     defined.  Since the signal numbers are allocated consecutively,
     `NSIG' is also one greater than the largest defined signal number.

* Menü:

* Program Error Signals::       Used to report serious program errors.
* Termination Signals::         Used to interrupt and/or terminate the
                                 program.
* Alarm Signals::               Used to indicate expiration of timers.
* Asynchronous I/O Signals::    Used to indicate input is available.
* Job Control Signals::         Signals used to support job control.
* Operation Error Signals::     Used to report operational system errors.
* Miscellaneous Signals::       Miscellaneous Signals.
* Signal Messages::             Printing a message describing a signal.


File: libc.info,  Node: Program Error Signals,  Next: Termination Signals,  Up: Standard Signals

Program Error Signals
---------------------

   The following signals are generated when a serious program error is
detected by the operating system or the computer itself.  In general,
all of these signals are indications that your program is seriously
broken in some way, and there's usually no way to continue the
computation which encountered the error.

   Some programs handle program error signals in order to tidy up before
terminating; for example, programs that turn off echoing of terminal
input should handle program error signals in order to turn echoing back
on.  The handler should end by specifying the default action for the
signal that happened and then reraising it; this will cause the program
to terminate with that signal, as if it had not had a handler.  (*Note
Termination in Handler::.)

   Termination is the sensible ultimate outcome from a program error in
most programs.  However, programming systems such as Lisp that can load
compiled user programs might need to keep executing even if a user
program incurs an error.  These programs have handlers which use
`longjmp' to return control to the command level.

   The default action for all of these signals is to cause the process
to terminate.  If you block or ignore these signals or establish
handlers for them that return normally, your program will probably
break horribly when such signals happen, unless they are generated by
`raise' or `kill' instead of a real error.

   When one of these program error signals terminates a process, it also
writes a "core dump file" which records the state of the process at the
time of termination.  The core dump file is named `core' and is written
in whichever directory is current in the process at the time.  (On the
GNU system, you can specify the file name for core dumps with the
environment variable `COREFILE'.)  The purpose of core dump files is so
that you can examine them with a debugger to investigate what caused
the error.

 - Macro: int SIGFPE
     The `SIGFPE' signal reports a fatal arithmetic error.  Although the
     name is derived from "floating-point exception", this signal
     actually covers all arithmetic errors, including division by zero
     and overflow.  If a program stores integer data in a location
     which is then used in a floating-point operation, this often
     causes an "invalid operation" exception, because the processor
     cannot recognize the data as a floating-point number.

     Actual floating-point exceptions are a complicated subject because
     there are many types of exceptions with subtly different meanings,
     and the `SIGFPE' signal doesn't distinguish between them.  The
     `IEEE Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Std
     754-1985 and ANSI/IEEE Std 854-1987)' defines various
     floating-point exceptions and requires conforming computer systems
     to report their occurrences.  However, this standard does not
     specify how the exceptions are reported, or what kinds of handling
     and control the operating system can offer to the programmer.

   BSD systems provide the `SIGFPE' handler with an extra argument that
distinguishes various causes of the exception.  In order to access this
argument, you must define the handler to accept two arguments, which
means you must cast it to a one-argument function type in order to
establish the handler.  The GNU library does provide this extra
argument, but the value is meaningful only on operating systems that
provide the information (BSD systems and GNU systems).

`FPE_INTOVF_TRAP'
     Integer overflow (impossible in a C program unless you enable
     overflow trapping in a hardware-specific fashion).

`FPE_INTDIV_TRAP'
     Integer division by zero.

`FPE_SUBRNG_TRAP'
     Subscript-range (something that C programs never check for).

`FPE_FLTOVF_TRAP'
     Floating overflow trap.

`FPE_FLTDIV_TRAP'
     Floating/decimal division by zero.

`FPE_FLTUND_TRAP'
     Floating underflow trap.  (Trapping on floating underflow is not
     normally enabled.)

`FPE_DECOVF_TRAP'
     Decimal overflow trap.  (Only a few machines have decimal
     arithmetic and C never uses it.)

 - Macro: int SIGILL
     The name of this signal is derived from "illegal instruction"; it
     usually means your program is trying to execute garbage or a
     privileged instruction.  Since the C compiler generates only valid
     instructions, `SIGILL' typically indicates that the executable
     file is corrupted, or that you are trying to execute data.  Some
     common ways of getting into the latter situation are by passing an
     invalid object where a pointer to a function was expected, or by
     writing past the end of an automatic array (or similar problems
     with pointers to automatic variables) and corrupting other data on
     the stack such as the return address of a stack frame.

     `SIGILL' can also be generated when the stack overflows, or when
     the system has trouble running the handler for a signal.

 - Macro: int SIGSEGV
     This signal is generated when a program tries to read or write
     outside the memory that is allocated for it, or to write memory
     that can only be read.  (Actually, the signals only occur when the
     program goes far enough outside to be detected by the system's
     memory protection mechanism.)  The name is an abbreviation for
     "segmentation violation".

     Common ways of getting a `SIGSEGV' condition include dereferencing
     a null or uninitialized pointer, or when you use a pointer to step
     through an array, but fail to check for the end of the array.  It
     varies among systems whether dereferencing a null pointer generates
     `SIGSEGV' or `SIGBUS'.

 - Macro: int SIGBUS
     This signal is generated when an invalid pointer is dereferenced.
     Like `SIGSEGV', this signal is typically the result of
     dereferencing an uninitialized pointer.  The difference between
     the two is that `SIGSEGV' indicates an invalid access to valid
     memory, while `SIGBUS' indicates an access to an invalid address.
     In particular, `SIGBUS' signals often result from dereferencing a
     misaligned pointer, such as referring to a four-word integer at an
     address not divisible by four.  (Each kind of computer has its own
     requirements for address alignment.)

     The name of this signal is an abbreviation for "bus error".

 - Macro: int SIGABRT
     This signal indicates an error detected by the program itself and
     reported by calling `abort'.  *Note Aborting a Program::.

 - Macro: int SIGIOT
     Generated by the PDP-11 "iot" instruction.  On most machines, this
     is just another name for `SIGABRT'.

 - Macro: int SIGTRAP
     Generated by the machine's breakpoint instruction, and possibly
     other trap instructions.  This signal is used by debuggers.  Your
     program will probably only see `SIGTRAP' if it is somehow
     executing bad instructions.

 - Macro: int SIGEMT
     Emulator trap; this results from certain unimplemented instructions
     which might be emulated in software, or the operating system's
     failure to properly emulate them.

 - Macro: int SIGSYS
     Bad system call; that is to say, the instruction to trap to the
     operating system was executed, but the code number for the system
     call to perform was invalid.


File: libc.info,  Node: Termination Signals,  Next: Alarm Signals,  Prev: Program Error Signals,  Up: Standard Signals

Termination Signals
-------------------

   These signals are all used to tell a process to terminate, in one way
or another.  They have different names because they're used for slightly
different purposes, and programs might want to handle them differently.

   The reason for handling these signals is usually so your program can
tidy up as appropriate before actually terminating.  For example, you
might want to save state information, delete temporary files, or restore
the previous terminal modes.  Such a handler should end by specifying
the default action for the signal that happened and then reraising it;
this will cause the program to terminate with that signal, as if it had
not had a handler.  (*Note Termination in Handler::.)

   The (obvious) default action for all of these signals is to cause the
process to terminate.

 - Macro: int SIGTERM
     The `SIGTERM' signal is a generic signal used to cause program
     termination.  Unlike `SIGKILL', this signal can be blocked,
     handled, and ignored.  It is the normal way to politely ask a
     program to terminate.

     The shell command `kill' generates `SIGTERM' by default.

 - Macro: int SIGINT
     The `SIGINT' ("program interrupt") signal is sent when the user
     types the INTR character (normally `C-c').  *Note Special
     Characters::, for information about terminal driver support for
     `C-c'.

 - Macro: int SIGQUIT
     The `SIGQUIT' signal is similar to `SIGINT', except that it's
     controlled by a different key--the QUIT character, usually
     `C-\'--and produces a core dump when it terminates the process,
     just like a program error signal.  You can think of this as a
     program error condition "detected" by the user.

     *Note Program Error Signals::, for information about core dumps.
     *Note Special Characters::, for information about terminal driver
     support.

     Certain kinds of cleanups are best omitted in handling `SIGQUIT'.
     For example, if the program creates temporary files, it should
     handle the other termination requests by deleting the temporary
     files.  But it is better for `SIGQUIT' not to delete them, so that
     the user can examine them in conjunction with the core dump.

 - Macro: int SIGKILL
     The `SIGKILL' signal is used to cause immediate program
     termination.  It cannot be handled or ignored, and is therefore
     always fatal.  It is also not possible to block this signal.

     This signal is usually generated only by explicit request.  Since
     it cannot be handled, you should generate it only as a last
     resort, after first trying a less drastic method such as `C-c' or
     `SIGTERM'.  If a process does not respond to any other termination
     signals, sending it a `SIGKILL' signal will almost always cause it
     to go away.

     In fact, if `SIGKILL' fails to terminate a process, that by itself
     constitutes an operating system bug which you should report.

     The system will generate `SIGKILL' for a process itself under some
     unusual conditions where the program cannot possible continue to
     run (even to run a signal handler).

 - Macro: int SIGHUP
     The `SIGHUP' ("hang-up") signal is used to report that the user's
     terminal is disconnected, perhaps because a network or telephone
     connection was broken.  For more information about this, see *Note
     Control Modes::.

     This signal is also used to report the termination of the
     controlling process on a terminal to jobs associated with that
     session; this termination effectively disconnects all processes in
     the session from the controlling terminal.  For more information,
     see *Note Termination Internals::.


File: libc.info,  Node: Alarm Signals,  Next: Asynchronous I/O Signals,  Prev: Termination Signals,  Up: Standard Signals

Alarm Signals
-------------

   These signals are used to indicate the expiration of timers.  *Note
Setting an Alarm::, for information about functions that cause these
signals to be sent.

   The default behavior for these signals is to cause program
termination.  This default is rarely useful, but no other default would
be useful; most of the ways of using these signals would require
handler functions in any case.

 - Macro: int SIGALRM
     This signal typically indicates expiration of a timer that
     measures real or clock time.  It is used by the `alarm' function,
     for example.

 - Macro: int SIGVTALRM
     This signal typically indicates expiration of a timer that
     measures CPU time used by the current process.  The name is an
     abbreviation for "virtual time alarm".

 - Macro: int SIGPROF
     This signal is typically indicates expiration of a timer that
     measures both CPU time used by the current process, and CPU time
     expended on behalf of the process by the system.  Such a timer is
     used to implement code profiling facilities, hence the name of
     this signal.


File: libc.info,  Node: Asynchronous I/O Signals,  Next: Job Control Signals,  Prev: Alarm Signals,  Up: Standard Signals

Asynchronous I/O Signals
------------------------

   The signals listed in this section are used in conjunction with
asynchronous I/O facilities.  You have to take explicit action by
calling `fcntl' to enable a particular file descriptor to generate
these signals (*note Interrupt Input::.).  The default action for these
signals is to ignore them.

 - Macro: int SIGIO
     This signal is sent when a file descriptor is ready to perform
     input or output.

     On most operating systems, terminals and sockets are the only
     kinds of files that can generate `SIGIO'; other kinds, including
     ordinary files, never generate `SIGIO' even if you ask them to.

     In the GNU system `SIGIO' will always be generated properly if you
     successfully set asynchronous mode with `fcntl'.

 - Macro: int SIGURG
     This signal is sent when "urgent" or out-of-band data arrives on a
     socket.  *Note Out-of-Band Data::.

 - Macro: int SIGPOLL
     This is a System V signal name, more or less similar to `SIGIO'.
     It is defined only for compatibility.


File: libc.info,  Node: Job Control Signals,  Next: Operation Error Signals,  Prev: Asynchronous I/O Signals,  Up: Standard Signals

Job Control Signals
-------------------

   These signals are used to support job control.  If your system
doesn't support job control, then these macros are defined but the
signals themselves can't be raised or handled.

   You should generally leave these signals alone unless you really
understand how job control works.  *Note Job Control::.

 - Macro: int SIGCHLD
     This signal is sent to a parent process whenever one of its child
     processes terminates or stops.

     The default action for this signal is to ignore it.  If you
     establish a handler for this signal while there are child
     processes that have terminated but not reported their status via
     `wait' or `waitpid' (*note Process Completion::.), whether your
     new handler applies to those processes or not depends on the
     particular operating system.

 - Macro: int SIGCLD
     This is an obsolete name for `SIGCHLD'.

 - Macro: int SIGCONT
     You can send a `SIGCONT' signal to a process to make it continue.
     This signal is special--it always makes the process continue if it
     is stopped, before the signal is delivered.  The default behavior
     is to do nothing else.  You cannot block this signal.  You can set
     a handler, but `SIGCONT' always makes the process continue
     regardless.

     Most programs have no reason to handle `SIGCONT'; they simply
     resume execution without realizing they were ever stopped.  You
     can use a handler for `SIGCONT' to make a program do something
     special when it is stopped and continued--for example, to reprint
     a prompt when it is suspended while waiting for input.

 - Macro: int SIGSTOP
     The `SIGSTOP' signal stops the process.  It cannot be handled,
     ignored, or blocked.

 - Macro: int SIGTSTP
     The `SIGTSTP' signal is an interactive stop signal.  Unlike
     `SIGSTOP', this signal can be handled and ignored.

     Your program should handle this signal if you have a special need
     to leave files or system tables in a secure state when a process is
     stopped.  For example, programs that turn off echoing should handle
     `SIGTSTP' so they can turn echoing back on before stopping.

     This signal is generated when the user types the SUSP character
     (normally `C-z').  For more information about terminal driver
     support, see *Note Special Characters::.

 - Macro: int SIGTTIN
     A process cannot read from the the user's terminal while it is
     running as a background job.  When any process in a background job
     tries to read from the terminal, all of the processes in the job
     are sent a `SIGTTIN' signal.  The default action for this signal
     is to stop the process.  For more information about how this
     interacts with the terminal driver, see *Note Access to the
     Terminal::.

 - Macro: int SIGTTOU
     This is similar to `SIGTTIN', but is generated when a process in a
     background job attempts to write to the terminal or set its modes.
     Again, the default action is to stop the process.  `SIGTTOU' is
     only generated for an attempt to write to the terminal if the
     `TOSTOP' output mode is set; *note Output Modes::..

   While a process is stopped, no more signals can be delivered to it
until it is continued, except `SIGKILL' signals and (obviously)
`SIGCONT' signals.  The signals are marked as pending, but not
delivered until the process is continued.  The `SIGKILL' signal always
causes termination of the process and can't be blocked, handled or
ignored.  You can ignore `SIGCONT', but it always causes the process to
be continued anyway if it is stopped.  Sending a `SIGCONT' signal to a
process causes any pending stop signals for that process to be
discarded.  Likewise, any pending `SIGCONT' signals for a process are
discarded when it receives a stop signal.

   When a process in an orphaned process group (*note Orphaned Process
Groups::.) receives a `SIGTSTP', `SIGTTIN', or `SIGTTOU' signal and
does not handle it, the process does not stop.  Stopping the process
would probably not be very useful, since there is no shell program that
will notice it stop and allow the user to continue it.  What happens
instead depends on the operating system you are using.  Some systems
may do nothing; others may deliver another signal instead, such as
`SIGKILL' or `SIGHUP'.  In the GNU system, the process dies with
`SIGKILL'; this avoids the problem of many stopped, orphaned processes
lying around the system.


File: libc.info,  Node: Operation Error Signals,  Next: Miscellaneous Signals,  Prev: Job Control Signals,  Up: Standard Signals

Operation Error Signals
-----------------------

   These signals are used to report various errors generated by an
operation done by the program.  They do not necessarily indicate a
programming error in the program, but an error that prevents an
operating system call from completing.  The default action for all of
them is to cause the process to terminate.

 - Macro: int SIGPIPE
     Broken pipe.  If you use pipes or FIFOs, you have to design your
     application so that one process opens the pipe for reading before
     another starts writing.  If the reading process never starts, or
     terminates unexpectedly, writing to the pipe or FIFO raises a
     `SIGPIPE' signal.  If `SIGPIPE' is blocked, handled or ignored,
     the offending call fails with `EPIPE' instead.

     Pipes and FIFO special files are discussed in more detail in *Note
     Pipes and FIFOs::.

     Another cause of `SIGPIPE' is when you try to output to a socket
     that isn't connected.  *Note Sending Data::.

 - Macro: int SIGLOST
     Resource lost.  This signal is generated when you have an advisory
     lock on an NFS file, and the NFS server reboots and forgets about
     your lock.

     In the GNU system, `SIGLOST' is generated when any server program
     dies unexpectedly.  It is usually fine to ignore the signal;
     whatever call was made to the server that died just returns an
     error.

 - Macro: int SIGXCPU
     CPU time limit exceeded.  This signal is generated when the process
     exceeds its soft resource limit on CPU time.  *Note Limits on
     Resources::.

 - Macro: int SIGXFSZ
     File size limit exceeded.  This signal is generated when the
     process attempts to extend a file so it exceeds the process's soft
     resource limit on file size.  *Note Limits on Resources::.


File: libc.info,  Node: Miscellaneous Signals,  Next: Signal Messages,  Prev: Operation Error Signals,  Up: Standard Signals

Miscellaneous Signals
---------------------

   These signals are used for various other purposes.  In general, they
will not affect your program unless it explicitly uses them for
something.

 - Macro: int SIGUSR1

 - Macro: int SIGUSR2
     The `SIGUSR1' and `SIGUSR2' signals are set aside for you to use
     any way you want.  They're useful for simple interprocess
     communication, if you write a signal handler for them in the
     program that receives the signal.

     There is an example showing the use of `SIGUSR1' and `SIGUSR2' in
     *Note Signaling Another Process::.

     The default action is to terminate the process.

 - Macro: int SIGWINCH
     Window size change.  This is generated on some systems (including
     GNU) when the terminal driver's record of the number of rows and
     columns on the screen is changed.  The default action is to ignore
     it.

     If a program does full-screen display, it should handle `SIGWINCH'.
     When the signal arrives, it should fetch the new screen size and
     reformat its display accordingly.

 - Macro: int SIGINFO
     Information request.  In 4.4 BSD and the GNU system, this signal
     is sent to all the processes in the foreground process group of
     the controlling terminal when the user types the STATUS character
     in canonical mode; *note Signal Characters::..

     If the process is the leader of the process group, the default
     action is to print some status information about the system and
     what the process is doing.  Otherwise the default is to do nothing.


File: libc.info,  Node: Signal Messages,  Prev: Miscellaneous Signals,  Up: Standard Signals

Signal Messages
---------------

   We mentioned above that the shell prints a message describing the
signal that terminated a child process.  The clean way to print a
message describing a signal is to use the functions `strsignal' and
`psignal'.  These functions use a signal number to specify which kind
of signal to describe.  The signal number may come from the termination
status of a child process (*note Process Completion::.) or it may come
from a signal handler in the same process.

 - Fonction: char * strsignal (int SIGNUM)
     This function returns a pointer to a statically-allocated string
     containing a message describing the signal SIGNUM.  You should not
     modify the contents of this string; and, since it can be rewritten
     on subsequent calls, you should save a copy of it if you need to
     reference it later.

     This function is a GNU extension, declared in the header file
     `string.h'.

 - Fonction: void psignal (int SIGNUM, const char *MESSAGE)
     This function prints a message describing the signal SIGNUM to the
     standard error output stream `stderr'; see *Note Standard
     Streams::.

     If you call `psignal' with a MESSAGE that is either a null pointer
     or an empty string, `psignal' just prints the message
     corresponding to SIGNUM, adding a trailing newline.

     If you supply a non-null MESSAGE argument, then `psignal' prefixes
     its output with this string.  It adds a colon and a space
     character to separate the MESSAGE from the string corresponding to
     SIGNUM.

     This function is a BSD feature, declared in the header file
     `signal.h'.

   There is also an array `sys_siglist' which contains the messages for
the various signal codes.  This array exists on BSD systems, unlike
`strsignal'.


File: libc.info,  Node: Signal Actions,  Next: Defining Handlers,  Prev: Standard Signals,  Up: Signal Handling

Specifying Signal Actions
=========================

   The simplest way to change the action for a signal is to use the
`signal' function.  You can specify a built-in action (such as to
ignore the signal), or you can "establish a handler".

   The GNU library also implements the more versatile `sigaction'
facility.  This section describes both facilities and gives suggestions
on which to use when.

* Menü:

* Basic Signal Handling::       The simple `signal' function.
* Advanced Signal Handling::    The more powerful `sigaction' function.
* Signal and Sigaction::        How those two functions interact.
* Sigaction Function Example::  An example of using the sigaction function.
* Flags for Sigaction::         Specifying options for signal handling.
* Initial Signal Actions::      How programs inherit signal actions.


File: libc.info,  Node: Basic Signal Handling,  Next: Advanced Signal Handling,  Up: Signal Actions

Basic Signal Handling
---------------------

   The `signal' function provides a simple interface for establishing
an action for a particular signal.  The function and associated macros
are declared in the header file `signal.h'.

 - Data Type: sighandler_t
     This is the type of signal handler functions.  Signal handlers
     take one integer argument specifying the signal number, and have
     return type `void'.  So, you should define handler functions like
     this:

          void HANDLER (int `signum') { ... }

     The name `sighandler_t' for this data type is a GNU extension.

 - Fonction: sighandler_t signal (int SIGNUM, sighandler_t ACTION)
     The `signal' function establishes ACTION as the action for the
     signal SIGNUM.

     The first argument, SIGNUM, identifies the signal whose behavior
     you want to control, and should be a signal number.  The proper
     way to specify a signal number is with one of the symbolic signal
     names described in *Note Standard Signals::--don't use an explicit
     number, because the numerical code for a given kind of signal may
     vary from operating system to operating system.

     The second argument, ACTION, specifies the action to use for the
     signal SIGNUM.  This can be one of the following:

    `SIG_DFL'
          `SIG_DFL' specifies the default action for the particular
          signal.  The default actions for various kinds of signals are
          stated in *Note Standard Signals::.

    `SIG_IGN'
          `SIG_IGN' specifies that the signal should be ignored.

          Your program generally should not ignore signals that
          represent serious events or that are normally used to request
          termination.  You cannot ignore the `SIGKILL' or `SIGSTOP'
          signals at all.  You can ignore program error signals like
          `SIGSEGV', but ignoring the error won't enable the program to
          continue executing meaningfully.  Ignoring user requests such
          as `SIGINT', `SIGQUIT', and `SIGTSTP' is unfriendly.

          When you do not wish signals to be delivered during a certain
          part of the program, the thing to do is to block them, not
          ignore them.  *Note Blocking Signals::.

    `HANDLER'
          Supply the address of a handler function in your program, to
          specify running this handler as the way to deliver the signal.

          For more information about defining signal handler functions,
          see *Note Defining Handlers::.

     If you set the action for a signal to `SIG_IGN', or if you set it
     to `SIG_DFL' and the default action is to ignore that signal, then
     any pending signals of that type are discarded (even if they are
     blocked).  Discarding the pending signals means that they will
     never be delivered, not even if you subsequently specify another
     action and unblock this kind of signal.

     The `signal' function returns the action that was previously in
     effect for the specified SIGNUM.  You can save this value and
     restore it later by calling `signal' again.

     If `signal' can't honor the request, it returns `SIG_ERR' instead.
     The following `errno' error conditions are defined for this
     function:

    `EINVAL'
          You specified an invalid SIGNUM; or you tried to ignore or
          provide a handler for `SIGKILL' or `SIGSTOP'.

   Here is a simple example of setting up a handler to delete temporary
files when certain fatal signals happen:

     #include <signal.h>
     
     void
     termination_handler (int signum)
     {
       struct temp_file *p;
     
       for (p = temp_file_list; p; p = p->next)
         unlink (p->name);
     }
     
     int
     main (void)
     {
       ...
       if (signal (SIGINT, termination_handler) == SIG_IGN)
         signal (SIGINT, SIG_IGN);
       if (signal (SIGHUP, termination_handler) == SIG_IGN)
         signal (SIGHUP, SIG_IGN);
       if (signal (SIGTERM, termination_handler) == SIG_IGN)
         signal (SIGTERM, SIG_IGN);
       ...
     }

Note how if a given signal was previously set to be ignored, this code
avoids altering that setting.  This is because non-job-control shells
often ignore certain signals when starting children, and it is important
for the children to respect this.

   We do not handle `SIGQUIT' or the program error signals in this
example because these are designed to provide information for debugging
(a core dump), and the temporary files may give useful information.

 - Fonction: sighandler_t ssignal (int SIGNUM, sighandler_t ACTION)
     The `ssignal' function does the same thing as `signal'; it is
     provided only for compatibility with SVID.

 - Macro: sighandler_t SIG_ERR
     The value of this macro is used as the return value from `signal'
     to indicate an error.

