jammy (2) signal.2.gz

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