michi@anvil.oz (Michael Henning) (07/25/89)
This probably belongs into comp.lang.c, but we do not get this group here,
and it is also relevant to C++.
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 AIX 2.2.1, the compiler produces an error message:
"line 1: void type for sig_type".
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++). All my references
seem to indicate that the typedef is OK, and the presence of the definition
in nn seems to indicate that at least some compilers accept it. Given that
a typedef looks like the equivalent variable declaration with the typedef
keyword added to establish the alias, but that it is not possible to declare
a variable of type void, does that mean that the typedef is automatically
invalid as well ?
Any help on this would really be appreciated. According to the C language
definition, the typedef is valid syntax. Are there any (defined) semantic
restrictions forbidding such a definition ?
Thanks,
Michi.
--
| Michael Henning | Internet : michi@anvil.oz{.au} |
| Anvil Designs | JANET : michi%anvil.oz@uk.ac.ukc |
| P.O. Box 954 | ARPA,Bitnet: michi%anvil.oz.au@uunet.uu.net |
| Toowong 4066, Australia | UUCP : ...!uunet!munnari!anvil.oz!michi |clyde@hitech.ht.oz (Clyde Smith-Stubbs) (07/27/89)
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