Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!necntc!linus!philabs!micomvax!ray
From: ray@micomvax.UUCP (Ray Dunn)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Ctrl-C trapping -- a hideous MS-DOS "feature"
Message-ID: <914@micomvax.UUCP>
Date: 26 Feb 88 15:32:11 GMT
References: <10277@ut-sally.UUCP>
Reply-To: ray@micomvax.UUCP (Ray Dunn)
Organization: Philips Electronics Ltd. (TDS - Montreal) St. Laurent P.Q., Canada
Lines: 24
Keywords: signal,SIGINT

In article <10277@ut-sally.UUCP> nather@ut-sally.UUCP (Ed Nather) writes:
>There are several ways to trap a "Ctrl-C" or "Ctrl-Break" keystroke
>if you have cleanup to do before your program exits.  I include one
>way in the attached sample program, but I have tried the interrupt
>intercept as described in Norton's "Programmers' Guide to the IBM
>PC" as well.  Both fail with the code below.  Ctrl-C is NOT trapped
>by either method.  (Both Microsoft C v4.0 and Turbo C v1.0 behave
>the same way; I'm sure MS-DOS is the culprit.....

Using Microsoft C v3.0 and 4.0 I have *NEVER* had any problems trapping ^C
using the "int (*signal(sig,func))()" feature with the manifest constant
SIGINT, eg:

    previous_ctrl_c_handler = signal(SIGINT, my_ctrl_c_handler);

This works perfectly, whether I want my_ctrl_c_handler to exit the program,
to continue after some processing (including reading input), or even to
redefine the ctrl C handler then continue.

RTFM.

This seems significantly simpler than the stuff Ed published & CERTAINLY
does not require assembler!

Ray Dunn.  ..philabs!micomvax!ray