Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!uhccux!munnari.oz.au!otc!uqcspe!hitech!clyde
From: clyde@hitech.ht.oz (Clyde Smith-Stubbs)
Newsgroups: comp.lang.c++
Subject: Re: typedef void
Message-ID: <284@hitech.ht.oz>
Date: 26 Jul 89 23:49:27 GMT
References: <653@anvil.oz>
Organization: HI-TECH Software, Brisbane, QLD, Australia
Lines: 35

From article <653@anvil.oz>, by michi@anvil.oz (Michael Henning):
> The recent posting of nn had a typedef relating to signal handlers to
> handle the differing return types of signal handlers. Example:
> 
> typedef void sig_type;
> 
> sig_type handler()
> {
> }
> 
> Under Xenix386 V2.3, the compiler gives:
> 
> 	"warning 43: 'sig_type' : void type changed to int".
> 
> My question is whether the above typedef is valid C (C++).

The answer is yes. Compilers that do not accept it (e.g. Xenix 2.3) are
at fault. Unfortunately there is little you can do about such compiler
shortcomings. I note also that the Xenix <signal.h> defines signal()
as returning a pointer to a function returning int, so strictly speaking
the definition of handler as void is incorrect under Xenix anyway (although
<sys/signal.h> seems to be unable to make up its mind whether it should
be void (*)() or int (*)()). It doesn't matter much under Xenix since
its standard header files do not use prototypes anyway, so no argument
checking is done. The ANSI draft defines signal() as

	void (*signal(int, void (*)(int)))(int);

------------------------
Clyde Smith-Stubbs
HI-TECH Software, P.O. Box 103, ALDERLEY, QLD, 4051, AUSTRALIA.

ACSnet:		clyde@hitech.ht.oz
INTERNET:	clyde@hitech.ht.oz.au		PHONE:	+61 7 300 5011
UUCP:		uunet!hitech.ht.oz.au!clyde	FAX:	+61 7 300 5246