CODEWITHSUNDEEP
coperating-systemsignals
Tim
Tim

Reputation: 99526

Are the signals in the C standard library <signal.h> signals in OS?

In <signal.h> of the C standard library, valid signals include 

SIGABRT  abnormal termination, e.g., from abort 
SIGFPE   arithmetic error, e.g., zero divide or overflow 
SIGILL   illegal function image, e.g., illegal instruction 
SIGINT   interactive attention, e.g., interrupt 
SIGSEGV  illegal storage access, e.g., access outside memory limits 
SIGTERM   termination request sent to this program

Are they the same signals implemented in the OS (e.g. Linux)? By that I mean the signals implemented in the OS are used by the OS to notify processes, which is independent of the C standard library and at a lower level of the C programming language and the C standard library.

To make my question more clear (as much as I could), let me draw an analogy. The exceptions and their handling in C++ isn't the same as the interrupts and their handling in an OS. The latter are implemented in the OS, and independent of the C++ programming language and at a lower level than C++.

Upvotes: 0

Views: 1694

Answers (4)

fuz
fuz

Reputation: 93117

In general, no. In specific cases, yes. The signalling specified by ISO/IEC 9899 is a stripped down (for portability) variant of the way signals work in UNIX. IEEE 1003.1 (POSIX) expands this to the full UNIX signalling API. However, it does not guarantee that the operating system uses the same system internally. Here are some examples.

Systems that use C signals interally

  • Linux
  • FreeBSD/NetBSD/OpenBSD
  • many other unices

Systems that do not use C signals internally

  • Plan 9 uses notes, the APE (ANSI/POSIX environment) compatibility layer translates notes to UNIX signals for programs written in standard C or against POSIX
  • Solaris uses a single signal handler per process. This however is invisible to the programmer as the libc translates this single signal type into traditional UNIX signals based on metadata coming with the signal
  • Windows and VMS use asynchronous procedure calls

Upvotes: 2

Jean-Baptiste Yun&#232;s
Jean-Baptiste Yun&#232;s

Reputation: 36431

Yes they are the same, at least C signals are supported by Linux, not necessarily the converse. In ancient times, there were no clear distinction in between C language and UNIX functions (aka system calls); remember that C was designed to write UNIX.

C standard 7.14 4/ :

An implementation need not generate any of these signals, except as a result of explicit calls to the raise function. Additional signals and pointers to undeclarable functions, with macro definitions beginning, respectively, with the letters SIG and an uppercase letter or with SIG_ and an uppercase letter,250) may also be specified by the implementation. The complete set of signals, their semantics, and their default handling is implementation-defined; all signal numbers shall be positive.

Your analogy is bad as exceptions are not interrupts. Exceptions are synchronous to your code, while interrupts aren't by nature.

Upvotes: 3

A. Gille
A. Gille

Reputation: 1048

Yes.

You can catch theses signals from your OS in your processes, or trig them from your processes to interact with the OS or other processes.

Have a look to this example.

Upvotes: 0

abligh
abligh

Reputation: 25169

Each of the signals specified in the include files for the standard C library are operating system signals (e.g. in Linux). The converse is not true, i.e. there may be OS signals that are not known by the standard C library.

On my system, there are 3 definitions for SIGABRT (all the same):

/usr/include/x86_64-linux-gnu/asm/signal.h:#define SIGABRT       6
/usr/include/x86_64-linux-gnu/bits/signum.h:#define SIGABRT     6   /* Abort (ANSI).  */
/usr/include/asm-generic/signal.h:#define SIGABRT        6

Note that it would be legal (but unusual) for the OS and the C library to use different values for the same signal.

Upvotes: 1

Related Questions