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 Unix, et a également varié selon les versions Linux. Évitez son utilisation : utilisez sigaction(2) à la place. Voir Portabilité plus loin. signal() définit la disposition du signal signum à handler, qui peut être SIG_IGN, SIG_DFL ou une fonction spécifique de l'utilisateur (un « gestionnaire de signal »). Si le signal signum est délivré au processus, un des événements suivants se produit :

*   Si la disposition est définie à SIG_IGN, le signal est ignoré.

*   Si la disposition est définie à SIG_DFL, l'action par défaut pour le signal est entreprise, comme décrit dans signal(7).

*   Si la disposition est définie à une fonction, alors tout d'abord la disposition est reconfigurée à SIG_DFL, ou le signal est bloqué, (voir Portabilité plus loin), puis handler est appelé 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 multi-fils (Ndt : thread) ne sont pas spécifié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. C'est peu 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. C'est peu recommandé.

VOIR AUSSI
kill(1), alarm(2), kill(2), killpg(2), pause(2), sigaction(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 22 décembre 2007.

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.