Provided by: manpages-fr-dev_3.27fr1.4-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
       varie au cours du temps dans les differentes versions de Linux.  'Evitez
       de  l'utiliser :  utilisez  plutot  sigaction(2).  Consultez la section
       Portabilit'e plus bas.

       signal() installe  le  gestionnaire  handler  pour  le  signal  signum.
       handler  peut etre SIG_IGN, SIG_DFL ou l'adresse d'une fonction definie
       par le programmeur (un << gestionnaire de signal >>).

       Lors de l'arrivee d'un signal correspondant au numero signum, l'un  des
       evenements suivants se produit :

       *  Si le gestionnaire vaut SIG_IGN, le signal est ignore.

       *  Si  le  gestionnaire  est SIG_DFL, l'action par defaut associee a ce
          signal est entreprise (consultez signal(7)).

       *  Si  le  gestionnaire  est  une  fonction,  alors  tout  d'abord   le
          gestionnaire  est  reconfigure  a   SIG_DFL, ou le signal est bloque
          (voir la section Portabilit'e ci-dessous), puis handler  est  appelee
          avec  l'argument signum. Si l'invocation du gestionnaire a bloque le
          signal, le signal est debloque au retour du gestionnaire.

       Les  signaux  SIGKILL  et  SIGSTOP  ne  peuvent  etre  ni  ignores,  ni
       interceptes.

VALEUR RENVOY'EE

       signal()  renvoie  la  valeur precedente du gestionnaire de signaux, ou
       SIG_ERR en cas d'erreur.

ERREURS

       EINVAL signum est invalide.

CONFORMIT'E

       C89, C99, POSIX.1-2001.

NOTES

       Les  effets  de  signal()   dans   un   processus   multithreade   sont
       indetermines.

       Comme  specifie  par POSIX, le comportement d'un processus est indefini
       apres la reception d'un signal SIGFPE, SIGILL, ou SIGSEGV qui  n'a  pas
       ete  engendre par une fonction kill(2) ou raise(3). La division entiere
       par zero a un  resultat  indefini,  sur  certaines  architectures  elle
       declenche  un  signal SIGFPE. De meme, diviser l'entier le plus negatif
       par -1 peut declencher SIGFPE.

       Consultez sigaction(2) pour des details sur ce qui se  passe  quand  on
       place SIGCHLD a SIG_IGN.

       Consultez  signal(7) pour une liste de fonctions sures pour les signaux
       asynchrones  qui  peuvent  etre  appelees  dans  les  gestionnaires  de
       signaux.

       L'utilisation  du  type  sighandler_t  est  une extension GNU. Diverses
       versions de la bibliotheque C predefinissent  ce  type.  Les  libc4  et
       libc5  definissaient  SignalHandler.  La  glibc  definit  sig_t  et, si
       _GNU_SOURCE est defini, sighandler_t egalement. Sans cette  definition,
       la declaration de signal() est plus difficile a lire :

           void ( *signal(int signum, void (*handler)(int)) ) (int);

   Portabilit'e
       La  seule  utilisation  portable  de  signal()  est de de configurer le
       gestionnaire du signal a SIG_DFL ou SIG_IGN. La semantique  associee  a
       l'utilisation de signal() pour definir un gestionnaire de signal depend
       suivant les systemes (et POSIX.1 autorise explicitement  ces  ecarts) ;
       ne l'utiliser pas pour cela.

       POSIX.1   a   resolu   ce   probleme   de  portabilite  est  specifiant
       sigaction(2), qui fournit un controle explicite de la semantique  quand
       un  gestionnaire de signal est appele ; utilisez cette interface plutot
       que signal().

       Dans les systemes Unix d'origine,  quand  un  gestionnaire  defini  par
       signal()   etait  appele  lors  de  la  distribution  d'un  signal,  le
       gestionnaire du signal etait remis a SIG_DFL, et le systeme ne bloquait
       pas la distribution des instances suivantes du signal. System V fournit
       egalement cette semantique pour  signal().  Ca  posait  probleme  parce
       qu'un  signal  pouvait  etre distribue avant que le gestionnaire ait le
       temps de se reactiver. De plus, la distribution rapide d'un meme signal
       pouvait causer des appels recursif au gestionnaire.

       BSD  a ameliore la situation en changeant la semantique du gestionnaire
       de signal (mais,malheureusement, changeat silencieusement la semantique
       pour  la definition d'un gestionnaire avec signal()). Sur BSD, quand un
       gestionnaire de signal est appele, le gestionnaire n'est  pas  remis  a
       zero,  et la distribution des instances suivantes du signal est bloquee
       tant que le gestionnaire s'execute.

       La situation sous Linux est la suivante :

       * L'appel systeme signal() du noyau fournit la semantique System V.

       * Par defaut,  dans  la  glibc 2  et  les  suivantes,  la  fonction  de
         bibliotheque signal() n'appelle pas l'appel systeme. A la place, elle
         appelle sigaction(2) est  fournissant  un  attribut  qui  fournit  la
         semantique  BSD.  Ce  comportement  par defaut est fourni tant que la
         macro de test de fonctionnalites _BSD_SOURCE est definie. Par defaut,
         _BSD_SOURCE est definie ; elle est egalement implicitement definie si
         on defini _GNU_SOURCE, et peut egalement etre definie explicitement.

         Dans  la  glibc 2  et  les  suivantes,  si  la  macro  de   test   de
         fonctionnalites  _BSD_SOURCE n'est pas definie, alors signal() fourni
         la semantique System V. (la definition implicite de  _BSD_SOURCE  par
         defaut  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 definie
         certaines   autres   macro   de   test   de   fonctionnalites   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
         semantique System V. Si on inclue <bsd/signal.h>  sur  une  libc5  au
         lieu de <signal.h>, alors signal() fournie la semantique BSD.

VOIR AUSSI

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

COLOPHON

       Cette page fait partie de  la  publication  3.27  du  projet  man-pages
       Linux.  Une description du projet et des instructions pour signaler des
       anomalies      peuvent      etre       trouvees       a       l'adresse
       <URL:http://www.kernel.org/doc/man-pages/>.

TRADUCTION

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

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

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

       Vous pouvez toujours avoir acces a la version anglaise de  ce  document
       en utilisant la commande << man -L C <section> <page_de_man> >>.