SunOS: 1; portability: 0

[Rahul Dhesi]

In article <11142 at smoke.BRL.MIL> gwyn at 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 Dhesi <dhesi%cirrusl at oliveb.ATC.olivetti.com>
UUCP:  oliveb!cirrusl!dhesi