Is `signal()` a system call function on Linux?

Question

From manpage of signal() http://man7.org/linux/man-pages/man2/signal.2.html

NAME top

  signal - ANSI C signal handling 

SYNOPSIS top

  #include <signal.h> typedef void (*sighandler_t)(int); sighandler_t signal(int signum, sighandler_t handler); 

The situation on Linux is as follows:

  * The kernel's signal() system call provides System V semantics. * 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. 

The quote seems to me that signal() is not a system call but a wrapper function implemented based on system call sigaction() , except "The kernel's signal() system call".

So is signal() a system call function or not on Linux?

Answer 1

The manpage for syscalls indicates the wrapper indirection is common, and has a list of Linux syscalls that includes signal(2) :

http://man7.org/linux/man-pages/man2/syscalls.2.html

Answer 2

There is a signal system call on Linux (see list of Linux system calls given by Jim). You never trap to a system call directly, you always call a wrapping function (at least you rarely generate the trap directly). As stated in the manual, signal() is just a wrapper to a system call that may not be the signal one (example is given for truncate in the document cited by @Jim). The signal() function is in the libc and that library is free to implement that function the way it want provided that the semantic is preserved. So as you mentioned a call to signal() may under given circumstances trap to signal system call or sigaction system call or whatever suitable.