Provided by: manpages-fr-dev_3.27fr1.4-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), feature_test_macros(7), signal(7)

COLOPHON

       Cette page fait partie de  la  publication  3.27  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> ».