Provided by: manpages-fr-dev_3.65d1p1-1_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

       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,  ou  SIG_ERR  en  cas
       d'erreur. En cas d'erreur, errno contient le code d'erreur.

ERREURS

       EINVAL signum est invalide.

CONFORMITÉ

       C89, C99, POSIX.1-2001.

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 on place SIGCHLD à
       SIG_IGN.

       Consultez signal(7) pour une liste de fonctions sûres pour  les  signaux  asynchrones  qui
       peuvent être appelées dans les gestionnaires 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  _GNU_SOURCE  est  définie.  Sans
       cette définition de ce type, la déclaration de signal() est 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. À 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 _BSD_SOURCE est définie. Par défaut, _BSD_SOURCE est
         définie ; elle est également implicitement définie si on  défini  _GNU_SOURCE,  et  peut
         également être définie explicitement.

         Dans  la  glibc 2  et  les suivantes, si la macro de test de fonctionnalités _BSD_SOURCE
         n'est pas  définie,  alors  signal()  fourni  la  sémantique  System V.  (la  définition
         implicite  de  _BSD_SOURCE  par défaut n'est pas fournie si on appelle gcc(1) dans un de
         ses modes demandant le respect  d'une  norme  (-std=xxx  ou  -ansi)  ou  si  on  définie
         certaines  autres macro de test de fonctionnalités comme _POSIX_SOURCE, _XOPEN_SOURCE ou
         _SVID_SOURCE ; consultez feature_test_macros(7).)

       * La fonction signal() de la  libc4  et  de  la  libc5  Linux  fournissent  la  sémantique
         System V.  Si  on  inclue  <bsd/signal.h>  sur  une  libc5  au lieu de <signal.h>, alors
         signal() fournie la sémantique BSD.

VOIR AUSSI

       kill(1), alarm(2), kill(2), killpg(2), pause(2), sigaction(2), signalfd(2), sigpending(2),
       sigprocmask(2),  sigsuspend(2),  bsd_signal(3),  raise(3),  siginterrupt(3),  sigqueue(3),
       sigsetops(3), sigvec(3), sysv_signal(3), signal(7)

COLOPHON

       Cette page fait partie de la publication 3.65 du projet man-pages Linux.  Une  description
       du  projet  et  des  instructions  pour  signaler  des  anomalies  peuvent être trouvées à
       l'adresse http://www.kernel.org/doc/man-pages/.

TRADUCTION

       Depuis   2010,   cette   traduction   est   maintenue   à   l'aide   de    l'outil    po4a
       <http://po4a.alioth.debian.org/>  par l'équipe de traduction francophone au sein du projet
       perkamon <http://perkamon.alioth.debian.org/>.

       Christophe   Blaess   <http://www.blaess.fr/christophe/>   (1996-2003),    Alain    Portal
       <http://manpagesfr.free.fr/>  (2003-2006).  Julien  Cristau  et  l'équipe  francophone  de
       traduction de Debian (2006-2009).

       Veuillez     signaler     toute     erreur     de     traduction     en     écrivant     à
       <debian-l10n-french@lists.debian.org>   ou   par   un  rapport  de  bogue  sur  le  paquet
       manpages-fr.

       Vous pouvez toujours avoir accès à la version anglaise de  ce  document  en  utilisant  la
       commande « man -L C <section> <page_de_man> ».