Xref: utzoo comp.unix.wizards:20631 comp.unix.questions:19973
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.unix.wizards,comp.unix.questions
Subject: Re: Passing SIGWINCH on from a signal handler
Keywords: Sun, SunOS, signal, SIGWINCH
Message-ID: <12168@smoke.BRL.MIL>
Date: 16 Feb 90 23:52:57 GMT
References: <1525@dinl.mmc.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Followup-To: comp.unix.wizards
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 29

In article <1525@dinl.mmc.UUCP> noren@dinl.UUCP (Chuck Noren) writes:
>When we installed it, we found that signal() returns
>a NULL the first time it is invoked.  

No, you get SIG_DFL.

>We were hoping to get the default signal handler for
>SIGWINCH so we could use it to have the SunOS do its
>normal window processing.

You cannot use the address of kernel code in your process address space.
Besides, it is unlikely that the kernel even establishes a signal handler
function like you're thinking of for the process; much more probably it
handles default actions for signals with special-purpose in-line code.

>We were wondering if there is a way to pass the
>signal on to the SunOS default signal handler after we
>process the signal ourselves.

#include <signal.h>
void application_signal_handler(int sig) {
	...
	// following system call not necessary if the signal state was
	// reset to SIG_DFL upon entry to this function, as required by
	// standards but unlike 4BSD:
	signal(sig, SIG_DFL);
	// repost the signal for this process:
	kill(getpid(), sig);
}