Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mel.connect.com.au!yarrina.connect.com.au!warrane.connect.com.au!news.syd.connect.com.au!gidora.kralizec.net.au!not-for-mail From: bde@zeta.org.au (Bruce Evans) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: Bogus gcc warning for SIG_DFL Date: 3 Jan 1996 17:47:13 +1100 Organization: Kralizec Dialup Unix Lines: 43 Message-ID: <4cd8ph$o1j@godzilla.zeta.org.au> References: <4ccd1j$1l8i@info4.rus.uni-stuttgart.de> NNTP-Posting-Host: godzilla.zeta.org.au In article <4ccd1j$1l8i@info4.rus.uni-stuttgart.de>, Jens Schweikhardt <schweikh@itosun.ito.uni-stuttgart.de> wrote: >Hello, > >Using SIG_DFL and compiling with -Wall gives a bogous warning. For > > #include <signal.h> > ... > signal (SIGALRM, SIG_DFL); > >gcc -Wall says >main.c:46: warning: function declaration isn't a prototype This is fixed in FreeBSD-2.1. >grepping for the SIG_DFL macro I find > > /usr/include/sys/signal.h:#define SIG_DFL (void (*)(int))0 > /usr/include/sys/signal.h:#define SIG_DFL (void (*)())0 > >of which two the latter one is the culprit; it is an oldstyle cast. >The first define is only taken when _ANSI_SOURCE is defined before >inclusion of <signal.h>. Alas, defining _ANSI_SOURCE lets hell break >lose: 50% of what's in <stdlib.h> is not prototyped anymore. > >I wonder why SIG_DFL is defined differently at all, depending on _ANSI_SOURCE. >The 'native' gcc is an ANSI compiler, so why worry about providing an old style >cast? Someone care to explain? Some non-standard-C conformant programs have signal handlers with the wrong number of args. This can't work in general, but happens to work on many systems (essentially those where the caller and not the callee removes function args from the stack after a function call; on the i386, it is faster for the callee to clean up the stack, but the conventionally the caller does it for compatibility with broken programs). The dependency on _ANSI_SOURCE was to hide this problem. At least for real signal handlers. For SIG_DFL, there is only a problem if the two definitions of SIG_DFL above give pointers with different representations. See also the comments in the 2.1 sys/signal.h. -- Bruce Evans bde@zeta.org.au