windows xp, I just downloaded the june 1st nightly build and it still does it.Yes it is a bug. In your code though, not in Code::Blocks.
That's wierd, because it works fine.
That's wierd, because it works fine.Well, I have been trying to catch SIGFPE, SIGILL, and SIGSEGV before, all of these do nothing, the program crashes as if there was no handler at all.
[...]
It works fine in linux, but if what you say is right then it shouldn't work in windows, but it does.
SIGINT is not supported for any Win32 application, including Windows 98/Me and Windows NT/2000/XP. When a CTRL+C interrupt occurs, Win32 operating systems generate a new thread to specifically handle that interrupt. This can cause a single-thread application such as UNIX, to become multithreaded, resulting in unexpected behavior.
#include <iostream>
#include <signal.h>
void sigCatch(int sig) {
signal(SIGINT, sigCatch);
std::cout << "caught signal" << std::endl;
}
int main(int argc, char *argv[])
{
int i = 0;
signal(SIGINT, sigCatch);
while (1) {
i++;
if (i == 100000000) {
std::cout << "You can't close me" << std::endl;
i = 0;
}
}
return 0;
}
I need to call signal(SIGINT, sigCatch) each time a SIGINT is thrown because the signal gets reset each time.That is normal System V / Linux glibc behaviour. Under BSD and Linux glibc2, the signal is not reset.
int wxKill(long pid, int sig = wxSIGTERM, wxKillError *rc = NULL, int flags = 0)
wxSIGNONE, wxSIGKILL and wxSIGTERM have the same meaning under both Unix and Windows but all the other signals are equivalent to wxSIGTERM under Windows.