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 aussi varié au cours du temps dans les
       différentes versions de Linux. Évitez de l'utiliser : utilisez plutôt sigaction(2). Consultez la  section
       Portabilité plus bas.

       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, l'un des événements suivants se produit :

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

       *  Si le gestionnaire est SIG_DFL, l'action par défaut associée à ce  signal  est  entreprise  (consultez
          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é  ci‐dessous),  puis  handler est appelée avec
          l'argument signum. Si l'invocation du gestionnaire a bloqué le  signal,  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. En cas
       d'erreur, errno contient le code d'erreur.

ERREURS

       EINVAL signum est invalide.

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 une fonction 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.  De
       même, diviser l'entier le plus négatif par -1 peut déclencher SIGFPE.

       Consultez sigaction(2) pour des détails sur ce qui se passe quand on place SIGCHLD à SIG_IGN.

       Consultez  signal(7)  pour  une  liste  de  fonctions sûres pour les signaux asynchrones qui peuvent être
       appelées dans les gestionnaires de signaux.

       L'utilisation du type sighandler_t est une extension GNU, exposée si _GNU_SOURCE est  définie.  La  glibc
       définit  aussi  sig_t  (dérivé  de  BSD) si _GNU_SOURCE est définie. Sans cette définition de ce type, la
       déclaration de signal() est plus difficile à lire :

           void ( *signal(int signum, void (*handler)(int)) ) (int);

   Portabilité
       La seule utilisation portable de signal() est de de configurer le gestionnaire du  signal  à  SIG_DFL  ou
       SIG_IGN. La sémantique associée à l'utilisation de signal() pour définir un gestionnaire de signal dépend
       suivant les systèmes (et POSIX.1 autorise explicitement ces écarts) ; ne l'utiliser pas pour cela.

       POSIX.1  a  résolu  ce  problème  de  portabilité  est  spécifiant  sigaction(2), qui fournit un contrôle
       explicite de la sémantique quand un gestionnaire de signal est appelé ; utilisez cette  interface  plutôt
       que signal().

       Dans  les  systèmes  UNIX  d'origine,  quand  un gestionnaire défini par signal() était appelé lors de la
       distribution d'un signal, le gestionnaire du signal était remis à SIG_DFL, et le système ne bloquait  pas
       la distribution des instances suivantes du signal. Cela revenait à appeler sigaction(2) avec les attribut
       suivants :

           sa.sa_flags = SA_RESETHAND | SA_NODEFER;

       System V  fournit  également  cette  sémantique  pour  signal().  Cela posait problème parce qu'un signal
       pouvait être distribué avant que le gestionnaire ait le temps de se réactiver. De plus,  la  distribution
       rapide d'un même signal pouvait causer des appels récursif au gestionnaire.

       BSD  a  amélioré  la  situation, mais a malheureusement également modifié la sémantique de l'interface de
       signal() en procédant de cette  façon.  Sous  BSD,  lorsqu'un  gestionnaire  de  signal  est  appelé,  la
       disposition  du  signal  n'est  pas  réinitialisée,  et les instances suivantes du signal ne peuvent être
       distribuées tant que le  gestionnaire  s'exécute.  En  outre,  certains  appels  système  bloquants  sont
       automatiquement  relancés  s'ils sont interrompus par le gestionnaire de signal (consultez signal(7)). La
       sémantique BSD est équivalente à un appel de sigaction(2) avec les attributs suivants :

           sa.sa_flags = SA_RESTART;

       La situation sous Linux est la suivante :

       * L'appel système signal() du noyau fournit la sémantique System V.

       * Par défaut, dans la glibc 2 et les suivantes,  la  fonction  de  bibliothèque  signal()  n'appelle  pas
         l'appel  système.  À  la  place,  elle  appelle sigaction(2) est fournissant un attribut qui fournit la
         sémantique BSD. Ce comportement par défaut est fourni tant que la  macro  de  test  de  fonctionnalités
         _BSD_SOURCE est définie. Par défaut, _BSD_SOURCE est définie ; elle est également implicitement définie
         si on défini _GNU_SOURCE, et peut également être définie explicitement.

         Dans la glibc 2 et les suivantes, si la macro de test de fonctionnalités _BSD_SOURCE n'est pas définie,
         alors  signal() fourni la sémantique System V. (la définition implicite de _BSD_SOURCE par défaut n'est
         pas fournie si on appelle gcc(1) dans un de ses modes demandant le respect  d'une  norme  (-std=xxx  ou
         -ansi)  ou  si  on  définie  certaines  autres  macro  de  test de fonctionnalités comme _POSIX_SOURCE,
         _XOPEN_SOURCE ou _SVID_SOURCE ; consultez feature_test_macros(7).)

       * La fonction signal() de la libc4 et de la libc5 Linux fournissent la sémantique System V. Si on  inclue
         <bsd/signal.h> sur une libc5 au lieu de <signal.h>, alors signal() fournie la sémantique BSD.

VOIR AUSSI

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

COLOPHON

       Cette page fait partie de la publication 3.65 du projet man-pages Linux. Une description du projet et des
       instructions     pour     signaler     des     anomalies    peuvent    être    trouvées    à    l'adresse
       http://www.kernel.org/doc/man-pages/.

TRADUCTION

       Depuis 2010, cette traduction est maintenue à l'aide de l'outil po4a <http://po4a.alioth.debian.org/> par
       l'équipe de traduction francophone au sein du projet perkamon <http://perkamon.alioth.debian.org/>.

       Christophe      Blaess      <http://www.blaess.fr/christophe/>      (1996-2003),       Alain       Portal
       <http://manpagesfr.free.fr/>  (2003-2006).  Julien  Cristau  et  l'équipe  francophone  de  traduction de
       Debian (2006-2009).

       Veuillez signaler toute erreur de traduction en écrivant à <debian-l10n-french@lists.debian.org>  ou  par
       un rapport de bogue sur le paquet manpages-fr.

       Vous pouvez toujours avoir accès à la version anglaise de ce document en utilisant la commande « man -L C
       <section> <page_de_man> ».

Linux                                             19 avril 2013                                        SIGNAL(2)