eric pouech (@epo) commented about programs/timeout/tests/timeout.c:
exitcode_expected, exitcode);}
+static BOOL WINAPI ctrl_handler(DWORD dwCtrlType) +{
- trace("Received dwCtrlType=%lu\n", dwCtrlType);
- return TRUE;
+}
static void test_ctrlc(void) {
- SetConsoleCtrlHandler(ctrl_handler, TRUE); run_timeout_ctrlc("", STATUS_CONTROL_C_EXIT); run_timeout_ctrlc("/nobreak", 1);
- SetConsoleCtrlHandler(ctrl_handler, FALSE);
that will unblock ctrl-c in this process and hence not prevent failure if ctrl-c is dispatched after this call
IMO, we have two options:
* disable ctrl-c before calling test_ctrlc() with a big comment (in main block) stating that after this point, ctrl-c shouldn't be reenabled (and removing all calls to SetConsoleCtrlC in test_ctrlc and its helpers) * use an intermediate process so that spurious ctrl-events will not affect parent (intermediate process be created with CREATE_NEW_PROCESS_GROUP | CREATE_NEW_CONSOLE)
I don't expect many changes in the future for these tests, so first option sounds valid (second is way cleaner but requires a bit more work)