Date:	Tue, 2 Feb 1999 12:14:47 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Paul Derbyshire <pderbysh AT usa DOT net>
cc:	djgpp AT delorie DOT com
Subject:	Re: SIGINT
In-Reply-To:	<3.0.6.32.19990202010752.008c17e0@pop.netaddress.com>
Message-ID:	<Pine.SUN.3.91.990202120706.13819a-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com

On Tue, 2 Feb 1999, Paul Derbyshire wrote:

> If a child process catches SIGINT and handles it internally rather than
> exiting because of it, is there a way for the parent to know that the
> SIGINT didn't cause an exit from the child?

In DJGPP or elsewhere?

In DJGPP, the only sure way is to look at the exit code.  If it is 255, 
and if the parent saw a SIGINT, then *probably* the child exited because 
of uncaught SIGINT.  But this is not bullet-proof, of course.

If your child is cooperative, you can get it to return a special exit 
code when it aborts because of SIGINT.

On Unix, the `wait' function and the macros on <sys/wait.h> supply the
necessary machinery to find out how did the child exit.  DJGPP supports 
the macros, but `wait' always fails, and some DOS compilers don't support 
the DOS conventions of exiting due to interrupt, so the sys/wait.h 
macros return wrong results.

> Alternatively, is there a way to tell after launching a child whether the
> child *exited due to* a signal of some kind? (It is easy to detect if any
> signals happened in the child. I mean differentiating whether one made it
> exit.)

See WIFEXITED, WIFSIGNALED, WTERMSIG, and the rest of the macros in 
sys/wait.h.  This is Posix-standard, so most modern Unix systems support 
those macros.

- Raw text -