signal - Gestion de signaux ANSI C.
 
SYNOPSIS
#include <signal.h>
typedef void (*sighandler_t)(int);
sighandler_t signal(int signum, sighandler_t handler);
 
DESCRIPTION
L'appel-système  signal()  installe  un nouveau gestionnaire pour le signal numéro signum.  Le gestionnaire de signal est handler qui peut être soit une fonction spécifique de l'utilisateur, soit une des constantes SIG_IGN ou SIG_DFL.
 
Lors de l'arrivée d'un signal correspondant au numéro signum, les événements suivants se produisent : si le  gestionnaire correspondant  est  configuré  avec  SIG_IGN, le signal est ignoré.  Si le gestionnaire vaut SIG_DFL, l'action par défaut pour le signal est entreprise, comme décrit dans signal(7).  Enfin, si le gestionnaire est dirigé vers une fonction  handler(), alors tout d'abord le gestionnaire est re-configuré à SIG_DFL, ou le signal est bloqué, puis handler() est appelé avec l'argument signum.
 
Utiliser une fonction comme gestionnaire de signal est appelé "intercepter -  ou  capturer  -  le  signal".  Les  signaux SIGKILL et SIGSTOP ne peuvent ni être ignorés, ni être interceptés.
 
VALEUR RENVOYÉE
La fonction signal() renvoie la valeur précédente du gestionnaire de signaux, ou SIG_ERR en cas d'erreur.
 
PORTABILITÉ
La  fonction signal() originale d'Unix réinitialisait le gestionnaire à SIG_DFL, comme c'est le cas sous Système V. Linux agissait ainsi avec les bibliothèques libc4 et libc5.  Au contraire, BSD ne réinitialise pas le gestionnaire, mais bloque les  éventuelles nouvelles occurences du signal durant l'appel de la fonction.  La bibliothèque GlibC 2 suit ce comportement.
 
Néanmoins, si l'on inclut sur un système sous libc5 <bsd/signal.h> à la place de <signal.h> alors signal est redéfini  en tant que __bsd_signal et disposera alors de la sémantique BSD. C'est peu recommandé.
 
Sur  un  système  fonctionnant  avec  la  GlibC  2, si on définit la constante _XOPEN_SOURCE ou si on utilise la fonction sysv_signal(), on obtient le comportement habituel. C'est peu recommandé.
 
La modification de la sémantique de l'appel en utilisant une constante symbolique ou un fichier d'en-tête  spécial n'est pas une bonne idée.  Il vaut mieux éviter d'utiliser signal() complètement, et utiliser plutôt sigaction(2).
 
NOTES
Comme  spécifié  par POSIX, le comportement d'un processus est indéfini après la réception d'un signal SIGFPE, SIGILL, ou SIGSEGV qui n'a pas été engendré par une fonction kill() ou  raise().   La  division  entière  par  zéro  a  un  résultat indéfini,  sur  certaines  architecture  elle  déclenche un signal SIGFPE.  Ignorer ce signal peut conduire à des boucles infinies.  De même diviser l'entier le plus négatif par -1 peut déclencher SIGFPE.
 
D'après POSIX (3.3.1.3) le comportement est indéfini si on positionne SIGCHLD à SIG_IGN.  Les comportements BSD  et  SYSV diffèrent, faisant échouer sous Linux les logiciels BSD qui positionne l'action de SIGCHLD à SIG_IGN.
 
L'utilisation du type sighandler_t est une extension GNU.  Diverses versions de la bibliothèque C prédéfinissent ce type. Les libc4 et libc5 définissaient SignalHandler, GlibC définit sig_t et, si _GNU_SOURCE est  défini,  sighandler_t  également.
 
CONFORMITÉ
ANSI C
 
VOIR AUSSI
kill(1), kill(2), killpg(2), pause(2), raise(3), sigaction(2), signal(7), sigsetops(3), sigvec(2), alarm(2)
 
TRADUCTION
Christophe Blaess, 1996-2003.
 
18 juillet 2003