Provided by: manpages-fr-dev_4.21.0-2_all bug

NOM

       signal - Gestion de signaux ANSI C

BIBLIOTHÈQUE

       Bibliothèque C standard (libc, -lc)

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.

STANDARDS

       POSIX.1-2001, POSIX.1-2008, 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)

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