XOPEN_SOURCE and signal handling

Question

In the following program, if I uncomment _XOPEN_SOURCE line, my program terminates when I hit C-c, same program doesn't terminate If I don't comment that line. Anyone knows in what ways does _XOPEN_SOURCE affect signal handling? I am on linux with gcc (4.6.3) and glibc (2.15).

/* #define _XOPEN_SOURCE 700 */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <signal.h>

typedef void (*sighandler_t)(int);

void handle_signal(int signo)
{
    printf("\n[MY_SHELL] ");
    fflush(stdout);
}

int main()
{
    int c;
    signal(SIGINT, SIG_IGN);
    signal(SIGINT, handle_signal);
    printf("[MY_SHELL] ");
    while ((c = getchar()) != EOF) {
        if (c == '\n')
            printf("[MY_SHELL] ");
    }
    printf("\n");
    return 0;
}

Answer 1

The problem is that the signal() function can have two different forms of behaviour when installing a signal handling function:

• System V semantics, where the signal handler is "one-shot" - that is, after the signal handling function is called, the signal's disposition is reset to SIG_DFL - and system calls that are interrupted by the signal are not restarted; or
• BSD semantics, where the signal handler is not reset when the signal fires, the signal is blocked whilst the signal handler is executing, and most interrupted system calls are automatically restarted.

On Linux with glibc, you get the BSD semantics if _BSD_SOURCE is defined, and the System V semantics if it is not. The _BSD_SOURCE macro is defined by default, but this default definition is suppressed if you define _XOPEN_SOURCE (or a few other macros too, like _POSIX_SOURCE and _SVID_SOURCE).

Under System V semantics, if the read() system call underlying getchar() is interrupted by SIGINT then getchar() will return EOF with errno set to EINTR (this will cause your program to exit normally). In addition, after the first SIGINT the disposition of this signal is reset to the default, and the default action for SIGINT is to terminate the process (so even if your program survived the first SIGINT, the second would cause it to exit abnormally).

The solution is not to use signal() at all for installing signal-handling functions; instead, you should use sigaction(), which is portable - it gives the same semantics everywhere. With sa_flags set to SA_RESTART, sigaction() it will give the BSD semantics, which is what you want.

Answer 2

These subtle behavorial differences are why sigprocmask() is usually preferred to signal() The version with _XOPEN_SOURCE 700 defined calls (as shown by strace)

rt_sigaction(SIGINT, {SIG_IGN, [], SA_INTERRUPT|SA_NODEFER|SA_RESETHAND}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGINT, {0x80484dc, [], SA_INTERRUPT|SA_NODEFER|SA_RESETHAND}, {SIG_IGN, [], SA_INTERRUPT|SA_NODEFER|SA_RESETHAND}, 8) = 0

Whereas the commented-out one calls:

rt_sigaction(SIGINT, {SIG_IGN, [INT], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0 
rt_sigaction(SIGINT, {0x80484dc, [INT], SA_RESTART}, {SIG_IGN, [INT], SA_RESTART}, 8) = 0

The important extra flag that _XOPEN_SOURCE lacks is SA_RESTART which allows the read system call to continue as if no signal occured. Without that, the system call indicates failure, getchar() returns -1 (but indicating failure, rather than a true EOF), and your program terminates.