Received: (from majordom@localhost)
	by hyperreal.org (8.8.5/8.8.5) id SAA11957;
	Sun, 3 Aug 1997 18:20:17 -0700 (PDT)
Received: from twinlark.arctic.org (twinlark.arctic.org [204.62.130.91])
	by hyperreal.org (8.8.5/8.8.5) with SMTP id SAA11943
	for <new-httpd@apache.org>; Sun, 3 Aug 1997 18:20:14 -0700 (PDT)
Received: (qmail 7192 invoked by uid 500); 4 Aug 1997 01:15:16 -0000
Date: Sun, 3 Aug 1997 18:15:15 -0700 (PDT)
From: Dean Gaudet <dgaudet@arctic.org>
To: new-httpd@apache.org
Subject: Re: someone please explain ap_signal
In-Reply-To: <Pine.BSF.3.95q.970803185951.1117K-100000@valis.worldgate.com>
Message-ID: <Pine.LNX.3.95dg3.970803181447.29846J-100000@twinlark.arctic.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

Well, you could change it so that we use ap_signal everywhere and don't
play with signal(). 

Dean

On Sun, 3 Aug 1997, Marc Slemko wrote:

> Gak.  Ok.  I understand, although I don't think I want to.  Perhaps a
> comment should be added.
> 
> Ok, so tell me what we do about PR#905, ie. compiling htdigest.
> 
> The problem is:
> 
> 	- htdigest includes ../src/md5c.c
> 	- md5c.c includes conf.h
> 	- conf.h redefines signal to ap_signal
> 	- the signal from http_main.c isn't included, so it don't work
> 
> We don't need our new signal in htdigest, so I am not inclined to change
> things so it is linked in there.
> 
> An OS may define signal to the_real_signal_that_works, so we can't just
> #undef signal after including md5c.c.
> 
> On Sun, 3 Aug 1997, Dean Gaudet wrote:
> 
> > 
> > 
> > On Sun, 3 Aug 1997, Marc Slemko wrote:
> > 
> > > On Sat, 26 Apr 1997 Roy wrote:
> > > 
> > > >>This patch can't be right -- all it does is redefine signal to
> > > >>a function that doesn't exist.  Either you forgot something,
> > > >>or your system's on drugs.
> > > >
> > > >Never mind -- Dean explained it to me.  I didn't know that you could
> > > >redefine both declarations and uses with #define.
> > > 
> > > #define signal(s,f)     ap_signal(s,f)
> > > Sigfunc *signal(int signo, Sigfunc *func);
> > > #endif
> > > 
> > > What does this do?  How?  Why?  Huh?
> > 
> > It replaces all occurances of signal with ap_signal, including the
> > definition of signal in http_main.c.  It is confusing, yes.  The
> > alternative is to explicitly use ap_signal everywhere, and assume module
> > writers haven't messed up... but, then, modules shouldn't be dinking with
> > signals anyhow. 
> > 
> > Dean
> > 
> > 
> 
>