SIGNAL(2)

NOM
signal - Gestion de signaux ANSI C

SYNOPSIS
#include <signal.h>

typedef void (*sighandler_t)(int);

sighandler_t signal(int signum, sighandler_t handler);

DESCRIPTION
Le comportement de signal() varie selon les versions d'Unix, et a également varié au cour du temps dans les différentes versions de Linux. Évitez son utilisation : utilisez plutôt sigaction(2). Voir Portabilité plus loin. signal() installe le gestionnaire handler pour le signal signum. handler peut être SIG_IGN, SIG_DFL ou l'adresse d'une fonction définie par le programmeur (un « gestionnaire de signal »). Lors de l'arrivée d'un signal correspondant au numéro signum, un des événements suivants se produit :

*   Si le gestionnaire est SIG_IGN, le signal est ignoré.

*   Si le gestionnaire est SIG_DFL, l'action par défaut associé à ce signal est entreprise, comme décrit dans signal(7).

*   Si le gestionnaire est une fonction, alors tout d'abord le gestionnaire est reconfiguré à SIG_DFL, ou le signal est bloqué, (voir la section Portabilité plus loin), puis handler est appelée avec l'argument signum. Si l'invocation du gestionnaire fait que le signal est bloqué, le signal est débloqué au retour du gestionnaire.

Les signaux SIGKILL et SIGSTOP ne peuvent être ni ignorés, ni interceptés.

VALEUR RENVOYÉE
signal() renvoie la valeur précédente du gestionnaire de signaux, ou SIG_ERR en cas d'erreur.

ERREURS

EINVAL
    signum n'est pas valide.

CONFORMITÉ
C89, C99, POSIX.1-2001.

NOTES
Les effets de signal() dans un processus multithreadé sont indéterminés.

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 kill(2) ou raise(3). La division entière par zéro a un résultat indéfini, sur certaines architectures 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.

Voir sigaction(2) pour plus de détails lorsque SIGCHLD vaut SIG_IGN.

Voir signal(7) pour une liste des fonctions sûres pour les signaux asynchrones qui peuvent être appelées par un gestionnaire de signaux.

L'utilisation du type sighandler_t est une extension GNU. Diverses versions de la glibc prédéfinissent ce type. Les libc4 et libc5 définissaient SignalHandler, glibc définit sig_t et, si _GNU_SOURCE est définie, sighandler_t également.

  Portabilité
La fonction signal() originale d'Unix réinitialisait le gestionnaire à SIG_DFL, comme c'est le cas sous System 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 occurrences du signal durant l'appel de la fonction. La bibliothèque glibc2 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. Ce n'est pas recommandé. Sur un système fonctionnant avec la glibc2, si on définit la constante _XOPEN_SOURCE ou si on utilise la fonction sysv_signal(3), on obtient le comportement habituel. Ce n'est pas recommandé.

VOIR AUSSI
kill(1), alarm(2), kill(2), killpg(2), pause(2), sigaction(2), signalfd(2), sigpending(2), sigprocmask(2), sigqueue(2), sigsuspend(2), bsd_signal(3), raise(3), siginterrupt(3), sigsetops(3), sigvec(3), sysv_signal(3), feature_test_macros(7), signal(7)

TRADUCTION

Ce document est une traduction réalisée par Christophe Blaess <http://www.blaess.fr/christophe/> le 13 octobre 1996 et révisée le 23 juin 2008.

L'équipe de traduction a fait le maximum pour réaliser une adaptation française de qualité. La version anglaise la plus à jour de ce document est toujours consultable via la commande : « LANG=C man 2 signal ». N'hésitez pas à signaler à l'auteur ou au traducteur, selon le cas, toute erreur dans cette page de manuel.