SKŁADNIA

#include <signal.h>

typedef void (*sighandler_t)(int);

sighandler_t signal(int signum, sighandler_t handler);

OPIS

Uwaga! To tłumaczenie może być nieaktualne!

Funkcja systemowa signal() instaluje nową obsługę sygnału dla sygnału o numerze signum. Obsługa sygnału ustawiana jest na sighandler, który może być funkcją podaną przez użytkownika lub SIG_IGN albo SIG_DFL.

Po przysłaniu sygnału o numerze signum dzieje się, co następuje. Jeśli obsługa odpowiedniego sygnału została ustawiona na SIG_IGN, to sygnał jest ignorowany. Jeśli obsługa została ustawiona na SIG_DFL, to podejmowana jest domyślna akcja skojarzona z sygnałem (patrz signal(7)). Ostatecznie, Jeśli jako obsługa sygnału została ustawiona function sighandler, to najpierw albo obsługa sygnału jest inicjowana na SIG_DFL albo odbywa się zależne od implementacji blokowanie sygnału, a następnie wywoływana jest funkcja sighandler z argumentem signum.

Używanie funkcji obsługi sygnału jest nazywane "przechwytywaniem sygnału". Sygnały SIGKILL i SIGSTOP nie mogą być ani przechwycone, ani zignorowane.

PRZENOŚNOŚĆ

Oryginalne uniksowe signal() zainicjalizowałoby obsługę sygnału na SIG_DFL i to samo robi System V (oraz jądro Linuksa i libc4,5). Z drugiej strony, BSD nie inicjalizuje obsługi sygnału, ale blokuje nowopojawiające się egzemplarze tego sygnału podczas wywoływania funkcji obsługi. Biblioteka glibc2 naśladuje zachowanie BSD.

Jeśli w systemie opartym o libc5 zostanie włączone <bsd/signal.h> zamiast <signal.h>, to signal zostanie przedefiniowane jako __bsd_signal i będzie miało semantykę BSD. Nie jest to zalecane.

Jeśli w systemie opartym o glibc2 zdefiniowane zostanie makro testowania cechy, takie jak _XOPEN_SOURCE lub zostanie użyta osobna funkcja sysv_signal, otrzyma się zachowanie klasyczne. Nie jest to zalecane.

Próba zmiany semantyki tej funkcji za pomocą przedefiniowywania i włączania plików nagłówkowych nie jest dobrym pomysłem. Lepiej w ogóle unikać funkcji signal i posługiwać się zamiast niej sigaction(2).

UWAGI

Zgodnie ze standardem POSIX, zachowanie procesu po zignorowaniu sygnału SIGFPE, SIGILL lub SIGSEGV, który nie był wygenerowany przez funkcję kill(2) ani raise(3), jest niezdefiniowane. Dzielenie przez zero liczby całkowitej nie ma określonego wyniku. Na niektórych architekturach generuje to sygnał SIGFPE. (Również dzielenie najmniejszej liczby ujemnej przez -1 może spowodować wygenerowanie SIGFPE.) Ignorowanie tego sygnału może doprowadzić do pętli nieskończonej.

Zgodnie ze standardem POSIX (3.3.1.3) nie jest określone, co sie stanie gdy SIGCHLD zostanie ustawiony na SIG_IGN. W tym miejscu zachowanie BSD i SYSV różni się, powodując nie działanie na Linuksie oprogramowania BSD, które ustawia akcję dla SIGCHLD na SIG_IGN.

Użycie sighandler_t jest rozszerzeniem GNU. Różne wersje libc predefiniują ten typ; libc4 i libc5 definiują SignalHandler, glibc definiuje sig_t, a gdy zdefiniowane jest _GNU_SOURCE, również sighandler_t.

ZGODNE Z

ANSI C

INFORMACJE O TŁUMACZENIU

Powyższe tłumaczenie pochodzi z nieistniejącego już Projektu Tłumaczenia Manuali i może nie być aktualne. W razie zauważenia różnic między powyższym opisem a rzeczywistym zachowaniem opisywanego programu lub funkcji, prosimy o zapoznanie się z oryginalną (angielską) wersją strony podręcznika za pomocą polecenia:

man --locale=C 2 signal

Prosimy o pomoc w aktualizacji stron man - więcej informacji można znaleźć pod adresem http://sourceforge.net/projects/manpages-pl/.