Provided by: manpages-fr-dev_3.32d0.2p4-1_all bug

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.

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.  Diverses  versions de la
       bibliothèque C prédéfinissent ce type. Les libc4 et libc5 définissaient SignalHandler.  La
       glibc  définit  sig_t  et,  si  _GNU_SOURCE est défini, sighandler_t également. Sans cette
       définition, 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. System V
       fournit également cette sémantique pour signal(). Ça 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  en  changeant  la  sémantique  du  gestionnaire  de  signal
       (mais,malheureusement,  changeât  silencieusement  la  sémantique  pour la définition d'un
       gestionnaire avec signal()). Sur BSD, quand un  gestionnaire  de  signal  est  appelé,  le
       gestionnaire  n'est pas remis à zéro, et la distribution des instances suivantes du signal
       est bloquée tant que le gestionnaire s'exécute.

       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),  sigqueue(2),  sigsuspend(2),  bsd_signal(3),  raise(3),  siginterrupt(3),
       sigsetops(3), sigvec(3), sysv_signal(3), signal(7)

COLOPHON

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

TRADUCTION

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

       Christophe  Blaess  <URL:http://www.blaess.fr/christophe/>   (1996-2003),   Alain   Portal
       <URL: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> ».