Or just use the type void (*)(int)
Printable View
Which compiler are you using?
gcc 3.4.2
For me, removing the explicit cast and changing the signature of handle_ctl_c to be "void handle_ctl_c()" let your sample code compile fine on gcc 4.1.2.
I'm starting to get that impression too. ;)
It's simple. My code is similar to that one.
I can't show it since it's huge, but it's the same thing.
My handler is this:
and i callCode:void handle_INT ()
{
printf ("An interrupt has occured...\n");
printf ("\n\n\n\n\n\n\n\n\n");
longjmp (jmp, 1);
}
in main.Code:signal (SIGINT, handle_INT)
I don't think ther eis anything else affecting this. I am getting the error message at the above line.
Crap!
I'm sorry guys, but i'm assigning the returned value of signal to an integer. I had not noticed that.
But i should assign it to a sighandler_t type right?
I do this: sighandler_t sig;
where sig is the assigned the return value but i get syntax error before sig.
It sounds like you should be using the SignalHandler type for the return value (the return value is the same type as the second parameter):
Quote:
RETURN VALUE
The signal() function returns the previous value of the signal handler, or SIG_ERR on error.
> It's simple. My code is similar to that one.
> I can't show it since it's huge, but it's the same thing.
It doesn't matter how similar you think it is, if it doesn't produce the stated error messages "as posted", you're just wasting everyones time on pointless guessing.
> longjmp (jmp, 1);
This seems to be an exceedingly dodgy thing to be doing inside a signal handler.
Read your manual pages to find out what is "Async-Safe" and stick to those only.
Ohhh boy. longjmp'ing out of a signal handler. You're getting a bit arcane now. I assume the corresponding setjmp() is located somewhere outside of a main loop of some kind? Are you SURE this is the only way to escape the loop?
Almost all blocking system calls will return early when a signal is caught, with the error code EINTR. The reason they do this is for exactly this reason -- you don't have to rely on longjmp() in order to escape out of a potentially forever-blocking call when a signal comes in. Just set a flag inside the signal handler, and check the flag after every potentially blocking call:
I every only encountered ONE case where the only solution to a problem with a longjmp() out of a signal handler, and that case is too horrifying to describe.Code:int ctrl_c_hit = 0;
void handle_ctrl_c()
{
ctrl_c_hit = 1;
}
void the_main_loop()
{
/* Loop forever */
for(;;)
{
/* A potentially blocking call */
read(1, buff, 1024);
if(ctrl_c_hit)
{
/* The user hit Ctrl-C. */
ctrl_c_hit = 0;
break;
}
}
}
EDIT: There are all kinds of fun race conditions to contend with, too. For the SIGINT signal, which is usually only delivered by Ctrl-C, the probability of running into problems is low. But in general you need to understand the principles of concurrent programming to write PROPER signal handlers.