<DD><CODE>SIG_DFL</CODE> specifies the default action for the particular signal.
The default actions for various kinds of signals are stated in
section <A HREF="library_21.html#SEC335" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_21.html#SEC335">Standard Signals</A>.
<P>
<A NAME="IDX1543"></A>
<A NAME="IDX1544"></A>
<DT><CODE>SIG_IGN</CODE>
<DD><CODE>SIG_IGN</CODE> specifies that the signal should be ignored.
<P>
Your program generally should not ignore signals that represent serious
events or that are normally used to request termination.  You cannot
ignore the <CODE>SIGKILL</CODE> or <CODE>SIGSTOP</CODE> signals at all.  You can
ignore program error signals like <CODE>SIGSEGV</CODE>, but ignoring the error
won't enable the program to continue executing meaningfully.  Ignoring
user requests such as <CODE>SIGINT</CODE>, <CODE>SIGQUIT</CODE>, and <CODE>SIGTSTP</CODE>
is unfriendly.
<P>
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.
See section <A HREF="library_21.html#SEC368" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_21.html#SEC368">Blocking Signals</A>.
<P>
<DT><CODE><VAR>handler</VAR></CODE>
<DD>Supply the address of a handler function in your program, to specify
running this handler as the way to deliver the signal.
<P>
For more information about defining signal handler functions,
see section <A HREF="library_21.html#SEC351" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_21.html#SEC351">Defining Signal Handlers</A>.
</DL>
<P>
If you set the action for a signal to <CODE>SIG_IGN</CODE>, or if you set it
to <CODE>SIG_DFL</CODE> 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.
<P>
The <CODE>signal</CODE> function returns the action that was previously in
effect for the specified <VAR>signum</VAR>.  You can save this value and
restore it later by calling <CODE>signal</CODE> again.
<P>
If <CODE>signal</CODE> can't honor the request, it returns <CODE>SIG_ERR</CODE>
instead.  The following <CODE>errno</CODE> error conditions are defined for
this function:
<P>
<DL COMPACT>
<DT><CODE>EINVAL</CODE>
<DD>You specified an invalid <VAR>signum</VAR>; or you tried to ignore or provide
a handler for <CODE>SIGKILL</CODE> or <CODE>SIGSTOP</CODE>.
</DL>
<P>
Here is a simple example of setting up a handler to delete temporary
files when certain fatal signals happen:
<P>
<PRE>
#include &#60;signal.h&#62;

void
termination_handler (int signum)
{
  struct temp_file *p;

  for (p = temp_file_list; p; p = p-&#62;next)
    unlink (p-&#62;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);
  ...
}
</PRE>
<P>
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.
<P>
We do not handle <CODE>SIGQUIT</CODE> 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.
<P>
<A NAME="IDX1545"></A>
<U>Function:</U> sighandler_t <B>ssignal</B> <I>(int <VAR>signum</VAR>, sighandler_t <VAR>action</VAR>)</I><P>
The <CODE>ssignal</CODE> function does the same thing as <CODE>signal</CODE>; it is
provided only for compatibility with SVID.
<P>
<A NAME="IDX1546"></A>
<U>Macro:</U> sighandler_t <B>SIG_ERR</B><P>
The value of this macro is used as the return value from <CODE>signal</CODE>
to indicate an error.
<P>
<A NAME="IDX1547"></A>
<H3><A NAME="SEC346" HREF="library_toc.html#SEC346" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_toc.html#SEC346">Advanced Signal Handling</A></H3>
<P>
The <CODE>sigaction</CODE> function has the same basic effect as
<CODE>signal</CODE>: to specify how a signal should be handled by the process.
However, <CODE>sigaction</CODE> offers more control, at the expense of more
complexity.  In particular, <CODE>sigaction</CODE> allows you to specify
additional flags to control when the signal is generated and how the
handler is invoked.
<P>
The <CODE>sigaction</CODE> function is declared in <TT>`signal.h'</TT>.
<A NAME="IDX1548"></A>
<P>
<A NAME="IDX1549"></A>
<U>Data Type:</U> <B>struct sigaction</B><P>
Structures of type <CODE>struct sigaction</CODE> are used in the
<CODE>sigaction</CODE> function to specify all the information about how to
handle a particular signal.  This structure contains at least the
following members:
<P>
<DL COMPACT>
<DT><CODE>sighandler_t sa_handler</CODE>
<DD>This is used in the same way as the <VAR>action</VAR> argument to the
<CODE>signal</CODE> function.  The value can be <CODE>SIG_DFL</CODE>,
<CODE>SIG_IGN</CODE>, or a function pointer.  See section <A HREF="library_21.html#SEC345" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_21.html#SEC345">Basic Signal Handling</A>.
<P>
<DT><CODE>sigset_t sa_mask</CODE>
<DD>This specifies a set of signals to be blocked while the handler runs.
Blocking is explained in section <A HREF="library_21.html#SEC373" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_21.html#SEC373">Blocking Signals for a Handler</A>.  Note that the
signal that was delivered is automatically blocked by default before its
handler is started; this is true regardless of the value in
<CODE>sa_mask</CODE>.  If you want that signal not to be blocked within its
handler, you must write code in the handler to unblock it.
<P>
<DT><CODE>int sa_flags</CODE>
<DD>This specifies various flags which can affect the behavior of 
the signal.  These are described in more detail in section <A HREF="library_21.html#SEC349" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_21.html#SEC349">Flags for <CODE>sigaction</CODE></A>.
</DL>
<P>
<A NAME="IDX1550"></A>
<U>Function:</U> int <B>sigaction</B> <I>(int <VAR>signum</VAR>, const struct sigaction *<VAR>action</VAR>, struct sigaction *<VAR>old_action</VAR>)</I><P>
The <VAR>action</VAR> argument is used to set up a new action for the signal
<VAR>signum</VAR>, while the <VAR>old_action</VAR> argument is used to return
information about the action previously associated with this symbol.
(In other words, <VAR>old_action</VAR> has the same purpose as the
<CODE>signal</CODE> function's return value--you can check to see what the
old action in effect for the signal was, and restore it later if you
want.)
<P>
Either <VAR>action</VAR> or <VAR>old_action</VAR> can be a null pointer.  If
<VAR>old_action</VAR> is a null pointer, this simply suppresses the return
of information about the old action.  If <VAR>action</VAR> is a null pointer,
the action associated with the signal <VAR>signum</VAR> is unchanged; this
allows you to inquire about how a signal is being handled without changing
that handling.
<P>
The return value from <CODE>sigaction</CODE> is zero if it succeeds, and
<CODE>-1</CODE> on failure.  The following <CODE>errno</CODE> error conditions are
defined for this function:
<P>
<DL COMPACT>
<DT><CODE>EINVAL</CODE>
<DD>The <VAR>signum</VAR> argument is not valid, or you are trying to
trap or ignore <CODE>SIGKILL</CODE> or <CODE>SIGSTOP</CODE>.
</DL>
<P>
<H3><A NAME="SEC347" HREF="library_toc.html#SEC347" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_toc.html#SEC347">Interaction of <CODE>signal</CODE> and <CODE>sigaction</CODE></A></H3>
<P>
It's possible to use both the <CODE>signal</CODE> and <CODE>sigaction</CODE>
functions within a single program, but you have to be careful because
they can interact in slightly strange ways.
<P>
The <CODE>sigaction</CODE> function specifies more information than the
<CODE>signal</CODE> function, so the return value from <CODE>signal</CODE> cannot
express the full range of <CODE>sigaction</CODE> possibilities.  Therefore, if
you use <CODE>signal</CODE> to save and later reestablish an action, it may
not be able to reestablish properly a handler that was established with
<CODE>sigaction</CODE>.
<P>
To avoid having problems as a result, always use <CODE>sigaction</CODE> to
save and restore a handler if your program uses <CODE>sigaction</CODE> at all.
Since <CODE>sigaction</CODE> is more general, it can properly save and
reestablish any action, regardless of whether it was established
originally with <CODE>signal</CODE> or <CODE>sigaction</CODE>.
<P>
If you establish an action with <CODE>signal</CODE> and then examine it with
<CODE>sigaction</CODE>, the handler address that you get may not be the same
as what you specified with <CODE>signal</CODE>.  It may not even be suitable
for use as an action argument with <CODE>signal</CODE>.  But you can rely on
using it as an argument to <CODE>sigaction</CODE>.
<P>
So, you're better off using one or the other of the mechanisms
consistently within a single program.  
<P>
<STRONG>Portability Note:</STRONG> The basic <CODE>signal</CODE> function is a feature
of ANSI C, while <CODE>sigaction</CODE> is part of the POSIX.1 standard.  If
you are concerned about portability to non-POSIX systems, then you
should use the <CODE>signal</CODE> function instead.
<P>
<H3><A NAME="SEC348" HREF="library_toc.html#SEC348" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_toc.html#SEC348"><CODE>sigaction</CODE> Function Example</A></H3>
<P>
In section <A HREF="library_21.html#SEC345" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_21.html#SEC345">Basic Signal Handling</A>, we gave an example of establishing a
simple handler for termination signals using <CODE>signal</CODE>.  Here is an
equivalent example using <CODE>sigaction</CODE>:
<P>
<PRE>
#include &#60;signal.h&#62;

void
termination_handler (int signum)
{
  struct temp_file *p;

  for (p = temp_file_list; p; p = p-&#62;next)
    unlink (p-&#62;name);
}

int
main (void)
{
  ...
  struct sigaction new_action, old_action;

  /* Set up the structure to specify the new action. */
  new_action.sa_handler = termination_handler;
  sigemptyset (&#38;new_action.sa_mask);
  new_action.sa_flags = 0;

  sigaction (SIGINT, NULL, &#38;old_action);
  if (old_action.sa_handler != SIG_IGN)
    sigaction (SIGINT, &#38;new_action, NULL);
  sigaction (SIGHUP, NULL, &#38;old_action);
  if (old_action.sa_handler != SIG_IGN)
    sigaction (SIGHUP, &#38;new_action, NULL);
  sigaction (SIGTERM, NULL, &#38;old_action);
  if (old_action.sa_handler != SIG_IGN)
    sigaction (SIGTERM, &#38;new_action, NULL);
  ...
}
</PRE>
<P>
The program just loads the <CODE>new_action</CODE> structure with the desired
parameters and passes it in the <CODE>sigaction</CODE> call.  The usage of
<CODE>sigemptyset</CODE> is described later; see section <A HREF="library_21.html#SEC368" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_21.html#SEC368">Blocking Signals</A>.
<P>
As in the example using <CODE>signal</CODE>, we avoid handling signals
previously set to be ignored.  Here we can avoid altering the signal
handler even momentarily, by using the feature of <CODE>sigaction</CODE> that
lets us examine the current action without specifying a new one.
<P>
Here is another example.  It retrieves information about the current
action for <CODE>SIGINT</CODE> without changing that action.
<P>
<PRE>
struct sigaction query_action;

if (sigaction (SIGINT, NULL, &#38;query_action) &#60; 0)
  /* <CODE>sigaction</CODE> returns -1 in case of error. */