Question

Doing homework with signals and fork and have a problem with the signal.

I’ve created the function:

void trata_sinal_int() {
    char op[2];

    printf("\nTerminate? (y/n)\n");

    scanf("%s", op);

    if (op[0] == 'y') {
        printf("Bye Bye\n");
        exit(0);
    }

}

And in main I have:

signal(SIGINT, trata_sinal_int);

When I run this, and press CTRL ^C the function void trata_sinal_int() is called and I got the message.

If I press y program ends as expected but if I press n program still ends.
It is not returning to were he was before pressing CTRL ^C.

Is this supposed to happen?

Answer 1

It depends on which standard you are adhering to, but Standard C doesn’t allow you to do much more than modify a variable of type volatile sig_atomic_t or call _Exit (or abort() or signal()) from a signal handler. POSIX is a lot more lenient. Your code in your signal handler, replete with user interaction, is pushing beyond the limits of what even POSIX allows. Normally, you want your signal handler function to be small and svelte.

Note that the signal handler function should be:

void trata_sinal_int(int signum)
{

This allows you to compile without casts or compiler warnings about type mismatches.
The signal() function may reset the signal handler back to default behaviour when it is invoked; classically, it is necessary to reinstate the signal handler inside the signal handler:

    signal(signum, trata_sinal_int);

So far, that’s all pretty generic and semi-trivial.

When you type the Control-C, the system does go back to roughly where it was when the signal was originally received. However, what happens next depends on where it was (one of the reasons you have to be so very careful inside the handler). For example, if it was in the middle of manipulating the free list pointers inside malloc(), it would return there, but if you’d reinvoked malloc() inside the handler, all hell might be breaking loose. If you were inside a system call, then your call may be interrupted (return with an error indication and errno == EINTR), or it may resume where it left off. Otherwise, it should go back to where the calculation was running.

---

Here’s (a fixed up version of) your code built into a test rig. The pause() function waits for a signal before returning.

#include <stdio.h>
#include <signal.h>
#include <stdlib.h>
#include <unistd.h>

static void trata_sinal_int(int signum)
{
    char op[2];

    signal(signum, trata_sinal_int);

    printf("\nTerminate? (y/n)\n");
    scanf("%s", op);

    if (op[0] == 'y')
    {
        printf("Bye Bye\n");
        exit(0);
    }
}

int main(void)
{
    signal(SIGINT, trata_sinal_int);
    for (int i = 0; i < 3; i++)
    {
        printf("Pausing\n");
        pause();
        printf("Continuing\n");
    }
    printf("Exiting\n");
    return(0);
}

I should really point out that the scanf() is not very safe at all; a buffer of size 2 is an open invitation to buffer overflow. I’m also not error checking system calls.

I tested on Mac OS X 10.7.5, a BSD derivative. The chance are good that the resetting of signal() would be unnecessary on this platform, because BSD introduced ‘reliable signals’ a long time ago (pre-POSIX).

---

ISO/IEC 9899:2011 §7.14.1.1 The signal function

¶5 If the signal occurs other than as the result of calling the abort or raise function, the
behavior is undefined if the signal handler refers to any object with static or thread
storage duration that is not a lock-free atomic object other than by assigning a value to an
object declared as volatile sig_atomic_t, or the signal handler calls any function
in the standard library other than the abort function, the _Exit function, the
quick_exit function, or the signal function with the first argument equal to the
signal number corresponding to the signal that caused the invocation of the handler.
Furthermore, if such a call to the signal function results in a SIG_ERR return, the
value of errno is indeterminate.²⁵²⁾

²⁵²⁾ If any signal is generated by an asynchronous signal handler, the behavior is undefined.

The references to quick_exit() are new in C2011; they were not present in C1999.

POSIX 2008

The section on Signal Concepts goes through what is and is not allowed inside a signal handler under POSIX in considerable detail.