dwww Home | Manual pages | Find package

signal(2)                     System Calls Manual                    signal(2)

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  ver-
       sions  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.  hand-
       ler  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  gestion-
          naire  est  reconfiguré à  SIG_DFL, ou le signal est bloqué (voir la
          section Portabilité ci-dessous), puis handler est appelée avec l'ar-
          gument  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 intercep-
       té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étermi-
       né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  _DE-
       FAULT_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 ges-
       tionnaire 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 sigac-
       tion(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  si-
       gnal()  était  appelé  lors de la distribution d'un signal, le gestion-
       naire 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 ges-
       tionnaire 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 si-
       gnal(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 biblio-
          thè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),  sig-
       pending(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 Chris-
       tophe Blaess <https://www.blaess.fr/christophe/>, Stéphan  Rafin  <ste-
       phan.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.cou-
       lon@wanadoo.fr>, Julien Cristau <jcristau@debian.org>,  Thomas  Huriaux
       <thomas.huriaux@gmail.com>,  Nicolas François <nicolas.francois@centra-
       liens.net>, Florentin Duneau <fduneau@gmail.com>, Simon  Paillard  <si-
       mon.paillard@resel.enst-bretagne.fr>,    Denis   Barbier   <barbier@de-
       bian.org>, David Prévot  <david@tilapin.org>,  Cédric  Boutillier  <ce-
       dric.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⟩.

Pages du manuel de Linux 6.03   5 février 2023                       signal(2)

Generated by dwww version 1.15 on Sat Jun 29 00:26:35 CEST 2024.