typedef void (*sighandler_t)(int);

sighandler_t signal(int signum, sighandler_t handler);  

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.  

EINVAL

signum n'est pas valide.

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.  

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é.  

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 avril 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.

NOM

SYNOPSIS

DESCRIPTION

VALEUR RENVOYÉE

ERREURS

CONFORMITÉ

NOTES

Portabilité

VOIR AUSSI

TRADUCTION