signal

SIGNAL(2)                  Manuel du programmeur Linux                 SIGNAL(2)



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




Linux                           15 septembre 2017                      SIGNAL(2)