Provided by: manpages-fr-dev_4.13-4_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

       WARNING:
        the  behavior  of  signal() varies across UNIX versions, and has also varied historically
       across different  versions  of  Linux.  Avoid  its  use:  use  sigaction(2)  instead.  See
       Portability below.

       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É

       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.

       See  sigaction(2)   for  details  on  what  happens when the disposition SIGCHLD is set to
       SIG_IGN.

       See signal-safety(7)  for a list of the async-signal-safe functions  that  can  be  safely
       called from inside a signal handler.

       The  use of sighandler_t is a GNU extension, exposed if _GNU_SOURCE is defined; glibc also
       defines  (the  BSD-derived)   sig_t  if  _BSD_SOURCE  (glibc   2.19   and   earlier)    or
       _DEFAULT_SOURCE  (glibc  2.19  and  later)   is  defined.  Without use of such a type, the
       declaration of signal()  is the somewhat harder to read:

           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.

       – By  default,  in  glibc  2 and later, the signal()  wrapper function does not invoke the
         kernel system call.  Instead,  it  calls  sigaction(2)   using  flags  that  supply  BSD
         semantics. This default behavior is provided as long as a suitable feature test macro is
         defined: _BSD_SOURCE on glibc 2.19 and earlier or  _DEFAULT_SOURCE  in  glibc  2.19  and
         later.  (By default, these macros are defined; see feature_test_macros(7)  for details.)
         If such a feature test macro is not defined, then signal()  provides System V semantics.

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.10 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> et Frédéric Hantrais <fhantrais@gmail.com>

       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 ⟨⟩.