Path: utzoo!attcan!uunet!ginosko!gem.mps.ohio-state.edu!apple!oliveb!tymix!cirrusl!sun505!dhesi From: dhesi@sun505.UUCP (Rahul Dhesi) Newsgroups: comp.unix.questions Subject: Re: SunOS: 1; portability: 0 Message-ID: <892@cirrusl.UUCP> Date: 25 Sep 89 00:32:55 GMT References: <880@cirrusl.UUCP> <11142@smoke.BRL.MIL> Sender: news@cirrusl.UUCP Reply-To: dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) Organization: Cirrus Logic Inc. Lines: 63 In article <11142@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) quotes me: >>For about ten years, signal() has been a function returning pointer to >>int. It worked, and we were all happily writing portable code. > >signal() has NEVER returned pointer to int. However, I know what you're >trying to say. Actually, once back in 1982, I caught a signal handler returning pointer to int when it thought nobody was looking... Sorry about my garbled thoughts, however. Yes, the type of signal() is pointer to function returning int, not function returning pointer to int. >Before the "void" type was added to C, one declared functions that >returned no value as "int"... [...other points...] Yes, I realize that since signal handlers don't return a value they should have a return type of void, not int. Yes, it's true that declaring them as returning int means the compiler must use appropriate linkage. Yes, a programmer could negligently try to make a signal handler return a value. Yes, void is better than int. >The ancient pre-"void" usage was simply incorrect. And this is where we disagree. Before the "void" data type existed, the c equivalent of a "procedure", i.e., a function from which no return value was needed, was by convention a function returning int. There is nothing actually wrong with this. Within the scope of the language rules, this was the accepted and correct way to do this. The new existense of the "void" data type did not suddenly make existing programs incorrect. It just gave us a better way to do the same thing. Not right versus wrong, just better versus not-so-good. [Note 1] As an analogy, the existence of the enum data type doesn't make it wrong to use the pre-enum technique of having a series of #defines. It just gives us a better of of doing the same thing. Since more than one person has suggested some sort of #define, I should point out that that is not an automatic solution. What *should* have been done by all the vendors/organizations who changed the type of signal was to guarantee the existence of a macro in signal.h so that I could then do: #ifdef SIGTYPE typdef sig_ret_t SIGTYPE #else /* if SIGTYPE not defined, we *know* it's int */ typedef sig_ret_t int #endif That would have made new code automatically portable and made the transition much easier. --- Note 1. Actually, I'm not fully convinced that signal handlers should return void rather than int. Letting them return int allows a future extension to signal handlers so that they *can* return a value. As an example, the return value from a SIGINT handler could tell the kernel whether or not to restart any interrupted system call. Rahul DhesiUUCP: oliveb!cirrusl!dhesi