Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!alicudi.usc.edu!crum
From: crum@alicudi.usc.edu (Gary L. Crum)
Newsgroups: gnu.g++
Subject: Re: bug? - compiles using 1.35.0+ but not 1.36.1
Message-ID: <CRUM.89Dec4204448@alicudi.usc.edu>
Date: 5 Dec 89 04:44:48 GMT
References: <CRUM.89Dec4195246@alicudi.usc.edu>
Sender: news@usc.edu
Distribution: gnu
Organization: University of Southern California
Lines: 41
In-reply-to: crum@alicudi.usc.edu's message of 5 Dec 89 03:52:46 GMT

Here is a sufficient explanation for the problem I described in my previous
posting.  I didn't realize that g++ 1.36 comes with a replacement for the
UNIX signal.h file.  I wish C++ include files had extensions other than .h.

Return-Path: <english@alicudi.usc.edu>
Date: Mon, 4 Dec 89 20:01:46 PST
From: english@alicudi.usc.edu (Joe English)
To: crum@alicudi.usc.edu, masotti@alicudi.usc.edu
Subject: Re: (EC++ problem with signals under v1.36)
Cc: agrawal@alicudi.usc.edu, requicha@alicudi.usc.edu


[Re: the problem with signal() in 1.35 vs. 1.36 ]

	The file /usr/include/signal.h is identical on both systems I use.

There is a 'signal.h' in /usr/public/lib/g++-include, 
though.  That defines:

	typedef void (*SignalHandler) (...);
	extern SignalHandler signal(int sig, SignalHandler action);

There is no 'signal.h' in the g++-include or gcc-include
directories in 1.35; just in 1.36.  I think that g++ and
gcc search these directories before they search /usr/include.

One note: you shouldn't use the function

	extern int badNews(int code=0, char* context="");

as a signal handler, since the operating system
passes different parameters to handler functions
(the signal code, a sigcontext structure, and two
other things that I can't remember.  It's at the end
of the man pages for sigvec(2), though).  SignalHandlers 
are probably declared as variadic in the GNU header file
because most handler functions choose to ignore the
parameters passed.


--Joe