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

       AVERTISSEMENT :  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.  En  cas  d'erreur,  il
       renvoie SIG_ERRs et errno est positionné pour indiquer l'erreur.

ERREURS

       EINVAL signum est invalide.

CONFORMITÉ

       POSIX.1-2001, POSIX.1-2008, C89, C99.

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 la posture de SIGCHLD
       est positionnée sur SIG_IGN.

       Consultez signal-safety(7) pour une liste de fonctions sûres pour les signaux  asynchrones
       qui peuvent être appelées dans un gestionnaire 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 _BSD_SOURCE (dans la  glibc  2.19
       ou  les précédentes) ou _DEFAULT_SOURCE (dans la glibc 2.19 et les suivantes) est définie.
       Sans cette définition de ce type, la déclaration de signal() est un peu 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  du  noyau.  À  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 est définie : _BSD_SOURCE dans la
         glibc 2.19 et les précédentes ou _DEFAULT_SOURCE dans la glibc  2.19  et  les  suivantes
         (par  défaut,  ces  macros  sont  définies ;  consultez  feature_test_macros(7) pour des
         détails). Si une telle macro de test de  fonctionnalités  n'est  pas  définie,  signal()
         fournit la sémantique de System V.

VOIR AUSSI

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

COLOPHON

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

TRADUCTION

       La  traduction  française  de  cette  page  de  manuel  a  été créée par Christophe Blaess
       <https://www.blaess.fr/christophe/>, Stéphan  Rafin  <stephan.rafin@laposte.net>,  Thierry
       Vignaud  <tvignaud@mandriva.com>,  François Micaux, Alain Portal <aportal@univ-montp2.fr>,
       Jean-Philippe   Guérard   <fevrier@tigreraye.org>,   Jean-Luc   Coulon   (f5ibh)    <jean-
       luc.coulon@wanadoo.fr>,    Julien    Cristau    <jcristau@debian.org>,    Thomas   Huriaux
       <thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centraliens.net>, Florentin
       Duneau  <fduneau@gmail.com>, Simon Paillard <simon.paillard@resel.enst-bretagne.fr>, Denis
       Barbier  <barbier@debian.org>,  David  Prévot   <david@tilapin.org>,   Cédric   Boutillier
       <cedric.boutillier@gmail.com>,  Frédéric  Hantrais  <fhantrais@gmail.com> et Jean-Philippe
       MENGUAL <jpmengual@debian.org>

       Cette traduction est une documentation libre ; veuillez vous reporter  à  la  GNU  General
       Public   License   version 3  ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩  concernant  les
       conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.

       Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un
       message à ⟨debian-l10n-french@lists.debian.org⟩.