Export (0) Print
Expand All
S
Expand Minimize

signal

Visual Studio 6.0

Sets interrupt signal handling.

void ( *signal( int sig, void (__cdecl *func) ( int sig [, int subcode ] )) ) ( int sig );

Routine Required Header Compatibility
signal <signal.h> ANSI, Win 95, Win NT

For additional compatibility information, see Compatibility in the Introduction.

Libraries

LIBC.LIB Single thread static library, retail version
LIBCMT.LIB Multithread static library, retail version
MSVCRT.LIB Import library for MSVCRT.DLL, retail version

Return Value

signal returns the previous value of func associated with the given signal. For example, if the previous value of func was SIG_IGN, the return value is also SIG_IGN. A return value of SIG_ERR indicates an error, in which case errno is set to EINVAL.

Parameters

sig

Signal value

func

Function to be executed

subcode

Optional subcode to the signal number

Remarks

The signal function allows a process to choose one of several ways to handle an interrupt signal from the operating system. The sig argument is the interrupt to which signal responds; it must be one of the following manifest constants, defined in SIGNAL.H.

sig Value Description
SIGABRT Abnormal termination
SIGFPE Floating-point error
SIGILL Illegal instruction
SIGINT CTRL+C signal
SIGSEGV Illegal storage access
SIGTERM Termination request

By default, signal terminates the calling program with exit code 3, regardless of the value of sig.

Note SIGINT is not supported for any Win32 application including Windows NT and Windows 95. When a CTRL+C interrupt occurs, Win32 operating systems generate a new thread to specifically handle that interrupt. This can cause a single-thread application such as UNIX, to become multithreaded, resulting in unexpected behavior.

The func argument is an address to a signal handler that you write, or one of the manifest constants SIG_DFL or SIG_IGN, also defined in SIGNAL.H. If func is a function, it is installed as the signal handler for the given signal. The signal handler’s prototype requires one formal argument, sig, of type int. The operating system provides the actual argument through sig when an interrupt occurs; the argument is the signal that generated the interrupt. Thus you can use the six manifest constants (listed in the preceding table) inside your signal handler to determine which interrupt occurred and take appropriate action. For example, you can call signal twice to assign the same handler to two different signals, then test the sig argument inside the handler to take different actions based on the signal received.

If you are testing for floating-point exceptions (SIGFPE), func points to a function that takes an optional second argument that is one of several manifest constants defined in FLOAT.H of the form FPE_xxx. When a SIGFPE signal occurs, you can test the value of the second argument to determine the type of floating-point exception and then take appropriate action. This argument and its possible values are Microsoft extensions.

For floating-point exceptions, the value of func is not reset upon receiving the signal. To recover from floating-point exceptions, use setjmp with longjmp. If the function returns, the calling process resumes execution with the floating-point state of the process left undefined.

If the signal handler returns, the calling process resumes execution immediately following the point at which it received the interrupt signal. This is true regardless of the type of signal or operating mode.

Before the specified function is executed, the value of func is set to SIG_DFL. The next interrupt signal is treated as described for SIG_DFL, unless an intervening call to signal specifies otherwise. This feature lets you reset signals in the called function.

Because signal-handler routines are usually called asynchronously when an interrupt occurs, your signal-handler function may get control when a run-time operation is incomplete and in an unknown state. The list below summarizes restrictions that determine which functions you can use in your signal-handler routine.

  • Do not issue low-level or STDIO.H I/O routines (such as printf and fread).

  • Do not call heap routines or any routine that uses the heap routines (such as malloc, _strdup, and _putenv). See malloc for more information.

  • Do not use any function that generates a system call (e.g., _getcwd, time).

  • Do not use longjmp unless the interrupt is caused by a floating-point exception (i.e., sig is SIGFPE). In this case, first reinitialize the floating-point package with a call to _fpreset.

  • Do not use any overlay routines.

A program must contain floating-point code if it is to trap the SIGFPE exception with the function. If your program does not have floating-point code and requires the run-time library’s signal-handling code, simply declare a volatile double and initialize it to zero:

volatile double d = 0.0f;

The SIGILL, SIGSEGV, and SIGTERM signals are not generated under Windows NT. They are included for ANSI compatibility. Thus you can set signal handlers for these signals with signal, and you can also explicitly generate these signals by calling raise.

Signal settings are not preserved in spawned processes created by calls to _exec or _spawn functions. The signal settings are reset to the default in the new process.

Process and Environment Control Routines

See Also   abort, _exec Functions, exit, _fpreset, _spawn Functions

Show:
© 2014 Microsoft