Provided by:
manpages-fr_1.67.0-1_all 
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
L’appel-système signal() installe un nouveau gestionnaire pour le
signal numéro signum. Le gestionnaire de signal est handler qui peut
être soit une fonction spécifique de l’utilisateur, soit une des
constantes SIG_IGN ou SIG_DFL.
Lors de l’arrivée d’un signal correspondant au numéro signum, les
événements suivants se produisent : si le gestionnaire correspondant
est configuré avec SIG_IGN, le signal est ignoré. Si le gestionnaire
vaut SIG_DFL, l’action par défaut pour le signal est entreprise, comme
décrit dans signal(7). Enfin, si le gestionnaire est dirigé vers une
fonction handler(), alors tout d’abord le gestionnaire est re-configuré
à SIG_DFL, ou le signal est bloqué, puis handler() est appelé avec
l’argument signum.
Utiliser une fonction comme gestionnaire de signal est appelé
« intercepter - ou capturer - le signal ». Les signaux SIGKILL et
SIGSTOP ne peuvent ni être ignorés, ni être interceptés.
VALEUR RENVOYÉE
La fonction signal() renvoie la valeur précédente du gestionnaire de
signaux, ou SIG_ERR en cas d’erreur.
PORTABILITÉ
La fonction signal() originale d’Unix réinitialisait le gestionnaire à
SIG_DFL, comme c’est le cas sous Système V. Linux agissait ainsi avec
les bibliothèques libc4 et libc5. Au contraire, BSD ne réinitialise
pas le gestionnaire, mais bloque les éventuelles nouvelles occurrences
du signal durant l’appel de la fonction. La bibliothèque GlibC 2 suit
ce comportement.
Néanmoins, si l’on inclut sur un système sous libc5 <bsd/signal.h> à la
place de <signal.h> alors signal est redéfini en tant que __bsd_signal
et disposera alors de la sémantique BSD. C’est peu recommandé.
Sur un système fonctionnant avec la GlibC 2, si on définit la constante
_XOPEN_SOURCE ou si on utilise la fonction sysv_signal(), on obtient le
comportement habituel. C’est peu recommandé.
La modification de la sémantique de l’appel en utilisant une constante
symbolique ou un fichier d’en-tête spécial n’est pas une bonne idée.
Il vaut mieux éviter d’utiliser signal() complètement, et utiliser
plutôt sigaction(2).
NOTES
Les effets de cet appel dans un processus multi-fils (Ndt : thread)
sont indéterminés.
La routine handler doit être très soigneuse car ailleurs, le traitement
peut avoir été interrompu à un endroit arbitraire. La spécification
POSIX dispose du concept de « fonction sûre ». Si un signal interrompt
une fonction non sûre et que handler appelle une fonction non sûre, le
comportement est indéterminé. Les fonctions sûres sont explicitement
listées dans les diverses normes. La liste de ces fonctions pour POSIX
1003.1-2003 est :
_Exit() _exit() abort() accept() access() aio_error() aio_return()
aio_suspend() alarm() bind() cfgetispeed() cfgetospeed() cfsetispeed()
cfsetospeed() chdir() chmod() chown() clock_gettime() close() connect()
creat() dup() dup2() execle() execve() fchmod() fchown() fcntl()
fdatasync() fork() fpathconf() fstat() fsync() ftruncate() getegid()
geteuid() getgid() getgroups() getpeername() getpgrp() getpid()
getppid() getsockname() getsockopt() getuid() kill() link() listen()
lseek() lstat() mkdir() mkfifo() open() pathconf() pause() pipe()
poll() posix_trace_event() pselect() raise() read() readlink() recv()
recvfrom() recvmsg() rename() rmdir() select() sem_post() send()
sendmsg() sendto() setgid() setpgid() setsid() setsockopt() setuid()
shutdown() sigaction() sigaddset() sigdelset() sigemptyset()
sigfillset() sigismember() signal() sigpause() sigpending()
sigprocmask() sigqueue() sigset() sigsuspend() sleep() socket()
socketpair() stat() symlink() sysconf() tcdrain() tcflow() tcflush()
tcgetattr() tcgetpgrp() tcsendbreak() tcsetattr() tcsetpgrp() time()
timer_getoverrun() timer_gettime() timer_settime() times() umask()
uname() unlink() utime() wait() waitpid() write().
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() ou raise(). La division entière
par zéro a un résultat indéfini, sur certaines architectures elle
déclenche un signal SIGFPE. Ignorer ce signal peut conduire à des
boucles infinies. De même, diviser l’entier le plus négatif par -1
peut déclencher SIGFPE.
D’après POSIX (3.3.1.3), le comportement est indéfini si on positionne
SIGCHLD à SIG_IGN. Les comportements BSD et SYSV diffèrent, faisant
échouer sous Linux les logiciels BSD qui positionne l’action de SIGCHLD
à SIG_IGN.
L’utilisation du type sighandler_t est une extension GNU. Diverses
versions de la bibliothèque C prédéfinissent ce type. Les libc4 et
libc5 définissaient SignalHandler, GlibC définit sig_t et, si
_GNU_SOURCE est défini, sighandler_t également.
CONFORMITÉ
ANSI C
VOIR AUSSI
kill(1), kill(2), killpg(2), pause(2), raise(3), sigaction(2),
signal(7), sigsetops(3), sigvec(2), alarm(2)
TRADUCTION
Christophe Blaess, 1996-2003.