crum@alicudi.usc.edu (Gary L. Crum) (12/05/89)
For the case where USENET folks out there want to take a whack at it,
I am posting a bug report that I sent to bug-g++ earlier today. Here it is:
Return-Path: <crum@alicudi.usc.edu>
Date: Mon, 4 Dec 89 17:18:36 PST
From: crum@alicudi.usc.edu (Gary L. Crum)
To: bug-g++@prep.ai.mit.edu
Cc: masotti@alicudi.usc.edu, action@alicudi.usc.edu
Subject: bug? - compiles using 1.35.0+ but not 1.36.1
I have include a program that compiles using g++ 1.35.0+ (on
panarea.usc.edu, a Sun-3/50 running SunOS 4.0.3) but not using g++ 1.36.1
(on alicudi.usc.edu, a Sun-4/60 running SunOS 4.0.3c). I am not completely
sure that my the problem indicates a bug in the new g++, because I am not
the person that works with g++ source code here. USC University Computing
Services (perhaps tli and/or mcooper at usc.edu) maintains GNU software
centrally for many Sun UNIX systems to NFS-mount.
The problem is related to using C function declarations in C++
using extern "C". It is not related to using the istream class in libg++.
To see the problem, you may follow these instructions:
1. Save this message as "msg" on a UNIX system.
2. Do "uudecode < msg; tar xpvof crumbug.tar; cd crumbug".
3. Do "make". A compiler error message occurs when
I attempt this with g++ 1.36.1, but not with g++ 1.35.0.
The uuencoded tar file used in above procedure is included at the end of
this message.
Here is a script of my attempt to compile "bug.cc" with 1.36.1, but it is
not necessary for you to look at this script if you don't want to.
My uucoded tar file attachment was meant to save you time by eliminating
the need for extracting code from this message.
---
alicudi:~/pal/g++_notes/crumbug g++ -version
gcc version 1.36.1 (based on GCC 1.36)
alicudi:~/pal/g++_notes/crumbug make
g++ -g -c bug.cc
bug.cc: In function void catch_signals ():
bug.cc:9: argument passing between incompatible pointer types
bug.cc:10: argument passing between incompatible pointer types
bug.cc:11: argument passing between incompatible pointer types
*** Error code 1
make: Fatal error: Command failed for target `bug.o'
alicudi:~/pal/g++_notes/crumbug
---
bug, when I compile "bug.cc" with 1.35.0+:
---
panarea:~/pal/g++_notes/crumbug g++ -version
g++ version 1.35.0+
panarea:~/pal/g++_notes/crumbug make
g++ -g -c bug.cc
panarea:~/pal/g++_notes/crumbug
---
The above (compile using g++ 1.35.0+) produces bug.o. Here is bug.cc:
---
extern "C" {
#include <signal.h>
}
extern int badNews(int code=0, char* context="");
void catch_signals()
{
signal(SIGFPE, badNews);
signal(SIGBUS, badNews);
signal(SIGSEGV, badNews);
}
---
The declaration of the function signal() in /usr/include/signal.h is:
---
void (*signal())();
---
The signal.h include files on both systems are identical.
My workaround is to use my own declaration for signal(), in the C++ style,
instead of using the system signal.h file. The declaration I use is:
---
#define SIGFPE 8 /* floating point exception */
#define SIGBUS 10 /* bus error */
#define SIGSEGV 11 /* segmentation violation */
extern void (*signal(int, void*))();
---
This is the end of my bug report. If you cannot address my report
immediately, then please acknowledge receipt of this message to avoid
a retransmission. I would appreciate such an acknowledgement.
Gary
begin 664 crumbug.tar
M8W)U;6)U9R\
M
M " @(#<W-2 (#$Q,#$S( @(#$S,#<@ " @(" @(" @(" P
M(" T-3,V-C$Q-30S(" @-34W-@ @
M
M
M
M
M
M
M
M !C<G5M8G5G+TUA:V5F:6QE
M
M (" @-C8T( @,3$P,3,@ " @
M,3,P-R (" @(" @(" @-C$@(#0U,S8V,#0U-3(@(" W,C8R "
M
M
M
M
M
M
M
M &1E9F%U;'0Z(&)U
M9RYO"@IB=6<N;SH@8G5G+F-C"@EG*RL@+6<@+6,@8G5G+F-C"@II;&4 9 T
M " !**L % &8G5G+F-C % O86QI8W5D:3(@-"XR(')W+&=R<&ED(#$@
M,@HO9&5V+W-D,F,@+VAO;64O86QI8W5D:2 T+C(@<G<L9W)P:60@,2 R"B]D
M978O<V0Q9" O:&]M92]A;&EC=61I,R T+C(@<G<L9W)P:60@,2 R"F%L:6-U
M9&DN=7-C+F5D=3HH<&ED,34W*2 O875T;R!N9G,@<F\L:6YT<BQP;W)T/3<U
M-"QM87 ];6]U;G1S+&EN9&ER96-T(# @, IL:7!A<FDZ+W5S<B]L:7!A<FD@
M+W1M<%]M;G0O875T;R]L:7!A<FD@;F9S(')W+&)G+'-O9G0L;F]Q=6]T82QG
M<G!I9"QT:6UE;STQ,"QR971R86YS/3,@," P"FUE<FQI;CHO97AP;W)T+W5S
M8R]S=6XT("]T;7!?;6YT+V%U=&\O=7-C+7-U;C0@;F9S(')W+&)G+&AA<F0L
M;F]Q=6]T82QG<G!I9"QT:6UE;STR,"QR971R86YS/3,@," P"FQI<&%R:3HO
M=7-R+W-P;V]L+VUA:6P@+W1M<%]M;G0O875T;R]M86EL(&YF<R!R=RQB9RQS
M;V9T+'%U8W)U;6)U9R]B=6<N8V,
M
M " @(#8V-" (#$Q,#$S( @(#$S,#<@ " @(" @
M(" @,S P(" T-3,V-C Q,S(V(" @-C<Q-@ @
M
M
M
M
M
M
M
M !E>'1E<FX@(D,B('L*(VEN8VQU9&4@
M/'-I9VYA;"YH/@I]"@IE>'1E<FX@:6YT(&)A9$YE=W,H:6YT(&-O9&4],"P@
M8VAA<BH@8V]N=&5X=#TB(BD["@IV;VED(&-A=&-H7W-I9VYA;',H*0I["@ES
M:6=N86PH4TE'1E!%+"!B861.97=S*3L*"7-I9VYA;"A324="55,L("!B861.
M97=S*3L*"7-I9VYA;"A324=314=6+"!B861.97=S*3L*?0II+G5S8RYE9'4Z
M*'!I9#$U-RD@+V%U=&\@;F9S(')O+&EN='(L<&]R=#TW-30L;6%P/6UO=6YT
M<RQI;F1I<F5C=" P(# *;&EP87)I.B]U<W(O;&EP87)I("]T;7!?;6YT+V%U
M=&\O;&EP87)I(&YF<R!R=RQB9RQS;V9T+&YO<75O=&$L9W)P:60L=&EM96\]
M,3 L<F5T<F%N<STS(# @, IM97)L:6XZ+V5X<&]R="]U<V,O<W5N-" O=&UP
M7VUN="]A=71O+W5S8RUS=6XT(&YF<R!R=RQB9RQH87)D+&YO<75O=&$L9W)P
M:60L=&EM96\],C L<F5T<F%N<STS(# @, IL:7!A<FDZ+W5S<B]S<&]O;"]M
M86EL("]T;7!?;6YT+V%U=&\O;6%I;"!N9G,@<G<L8F<L<V]F="QQ=0
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
"
endcrum@alicudi.usc.edu (Gary L. Crum) (12/05/89)
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