Which compiler are you using?
Naturally I didn't feel inspired enough to read all the links for you, since I already slaved away for long hours under a blistering sun pressing the search button after typing four whole words! - Quzah
You. Fetch me my copy of the Wall Street Journal. You two, fight to the death - Stewie
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.
Naturally I didn't feel inspired enough to read all the links for you, since I already slaved away for long hours under a blistering sun pressing the search button after typing four whole words! - Quzah
You. Fetch me my copy of the Wall Street Journal. You two, fight to the death - Stewie
I'm starting to get that impression too.
Naturally I didn't feel inspired enough to read all the links for you, since I already slaved away for long hours under a blistering sun pressing the search button after typing four whole words! - Quzah
You. Fetch me my copy of the Wall Street Journal. You two, fight to the death - Stewie
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):
RETURN VALUE
The signal() function returns the previous value of the signal handler, or SIG_ERR on error.
Naturally I didn't feel inspired enough to read all the links for you, since I already slaved away for long hours under a blistering sun pressing the search button after typing four whole words! - Quzah
You. Fetch me my copy of the Wall Street Journal. You two, fight to the death - Stewie
> 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.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
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.
Last edited by brewbuck; 04-11-2007 at 03:19 PM.