windows hates signal?

[hlinzhou]

I am interested in digging the include directory of my favorite gcc
compiler specialized for windows(yes u get it, I use Dev-C++, but I
love c and type commands in the console).But when I find signal.h and
try it, I meet some problems.My code is:

/*signal-win.c*/
#include <stdio.h>
#include <signal.h>
#include <windows.h>

#define SIGCUST 80

void ctrlc()
{
printf("no u can not kill me\n");
signal(SIGINT, ctrlc);
}

void chandler()
{
printf("SIGCUST caught!\n");
signal(SIGCUST, chandler);
}

int main()
{
int i;

signal(SIGINT, ctrlc);
signal(SIGCUST, chandler);
while(1)
{
printf("executing...\n");
raise(SIGCUST);
Sleep(1000);
}
return 0;
}

I included windows.h bcz I want to use Sleep() function.
When I run the binary code after 'gcc -o sig.exe signal-win.c', it
outputs only 'executing..' and 'no u can not kill me' when I type
ctrl-c, where is 'SIGCUST caught!'?Does it really like somebody
described 'windows fails to be a modern O.S. after it fails in
implementing the signal mechanism' or it is just my fault?
my gcc version is 3.4.2 (mingw-special)
Thanks

 

[=?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?=]

I am interested in digging the include directory of my favorite gcc
compiler specialized for windows(yes u get it, I use Dev-C++, but I
love c and type commands in the console).But when I find signal.h and
try it, I meet some problems.My code is:

/*signal-win.c*/
#include <stdio.h>
#include <signal.h>
#include <windows.h>

#define SIGCUST 80

signals are system defined. You can't define your own signals,
only install handlers/ignore the signals provided by the system.

Also - signal and raise return values. If you checked that for errors,
you might have realized you couldn't install or raise your SIGCUST
(unless 80 happened to be also the nr of a system defined signal..)

 

[stathis gotsis]

I am interested in digging the include directory of my favorite gcc
compiler specialized for windows(yes u get it, I use Dev-C++, but I
love c and type commands in the console).But when I find signal.h and
try it, I meet some problems.My code is:

/*signal-win.c*/
#include <stdio.h>
#include <signal.h>
#include <windows.h>

#define SIGCUST 80

void ctrlc()
{
printf("no u can not kill me\n");
signal(SIGINT, ctrlc);
}

void chandler()
{
printf("SIGCUST caught!\n");
signal(SIGCUST, chandler);
}

int main()
{
int i;

signal(SIGINT, ctrlc);
signal(SIGCUST, chandler);

Yes, maybe this is not a comp.lang.c question but:

void (*i)(int);
if ((i=signal(SIGCUST, chandler))==SIG_ERR)
printf("Signal handler not set\n");
That could be informative. Also open your "signal.h" file, it is
enlightening.

while(1)
{
printf("executing...\n");
raise(SIGCUST);

Maybe this does not return with zero.

 

[Walter Roberson]

void ctrlc()
{
printf("no u can not kill me\n");
signal(SIGINT, ctrlc);
}

void chandler()
{
printf("SIGCUST caught!\n");
signal(SIGCUST, chandler);
}

int main()
{
int i;

signal(SIGINT, ctrlc);
signal(SIGCUST, chandler);

You cannot use printf() inside a signal handler. In a signal
handler, you can set variables of type volatile sig_atomic_t
and you can re-set the signal handler for the signal you are
servicing, and you can use return, exit, abort, and longjump.
Any I/O operations are off-limit, as is setting any other kind of
variable. Exception: if you trigger the signal yourself using
abort() or raise() then you are permitted other [unspecified] freedoms.

 

[Richard Heathfield]

Walter Roberson said:

You cannot use printf() inside a signal handler.

Right, in the same way that you can't use a hockey stick in a football game.
(In other words, you /can/, but if you do, Something Bad might happen.

In a signal
handler, you can set variables of type volatile sig_atomic_t
and you can re-set the signal handler for the signal you are
servicing, and you can use return, exit, abort, and longjump.

longjmp (sorry to pick a spelling nit, but spelling matters when using
standard library functions).

 

[Jordan Abel]

You cannot use printf() inside a signal handler. In a signal
handler, you can set variables of type volatile sig_atomic_t
and you can re-set the signal handler for the signal you are
servicing, and you can use return, exit, abort, and longjump.

Hold on - you can use WHAT, now? I'd never heard about longjmp being
anything like "safe" within a signal handler.

Any I/O operations are off-limit, as is setting any other kind of
variable. Exception: if you trigger the signal yourself using
abort() or raise() then you are permitted other [unspecified] freedoms.

 

[Walter Roberson]

Hold on - you can use WHAT, now? I'd never heard about longjmp being
anything like "safe" within a signal handler.

Last time around, I overstated what could be done inside a handler,
so this time I looked it up in the official C89 standard and
listed the things it said there. I wasn't going from memory
this time around. But my C89 is at work so I can't quote exact
wording at the moment.

 

[Stefan Krah]

Last time around, I overstated what could be done inside a handler,
so this time I looked it up in the official C89 standard and
listed the things it said there. I wasn't going from memory
this time around. But my C89 is at work so I can't quote exact
wording at the moment.

As I read the C99 standard, you can use abort(), _Exit() and
signal(). The latter with limitations.

I don't have the C89 standard though.


Stefan Krah

 

[Michael Wojcik]

Hold on - you can use WHAT, now? I'd never heard about longjmp being
anything like "safe" within a signal handler.

I don't believe "safe" is defined by the standard, though it is used
in a number of places. However:

ISO 9899-1990 7.6.2.1 (The longjmp function):

As it bypasses the usual function call and return mechanisms, the
longjmp function shall execute correctly in contexts of interrupts,
signals and any of their associated functions. However, if the
longjmp function is invoked from a nested signal handler (that is,
from a function invoked as a result of a signal raised during the
handling of another signal), the behavior is undefined.

7.7.1.1 (The signal function):

The function func may terminate by executing a return statement or
by calling the abort, exit, or longjmp function.

So within various restrictions, C90 does endorse calling longjmp from
a signal handler.

C99, however, removes this endorsement; there is no corresponding
language in the descriptions of the two functions. (See 7.13 and
7.14 in 9899-1999, either the original or n1124.)