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

Linux                                           15 septembre 2017                                      SIGNAL(2)