SunOS: 1; portability: 0

[Doug Gwyn]

In article <880 at cirrusl.UUCP> dhesi%cirrusl at oliveb.ATC.olivetti.com (Rahul Dhesi) writes:
>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.

Before the "void" type was added to C, one declared functions that
returned no value as "int" (usually eliding the explicit "int", to
underscore the point that no value was actually being returned, despite
the declared function type).  That meant that signal handler functions,
which cannot return a value, were defined as functions returning
(implicit) int due to the lack of a better way to specify them.

After "void" was added to C around 1979, the opportunity existed to
correctly declare such function types as returning no value.  In fact
a "void"-cognizant "lint" would normally squawk about the lack of a
return value for a nominally int-valued function, and most "lint"s had
a kludge installed to shut them up in precisely the cases under discussion.

>So what happens?  Both Sun and ANSI decide that milliions of lines of
>existing code were all wrong, and that signal() ought really to return
>pointer to void.

Not pointer to void.

Actually, I instigated this change.  Larry Rossler had been unsuccessfully
arguing inside AT&T for the change ever since "void" appeared.  It was
quite apparent to X3J11 and P1003 that type correctness REQUIRED the
change.  The ancient pre-"void" usage was simply incorrect.  Signal
handlers DO NOT return an int value and it is WRONG to define them as
returning one.  This is not just a matter of theoretical "purity",
either, as the difference in return types can easily show up as a
difference in the linkage actually used in the function invocation.

The first widespread correct post-"void" version of <signal.h> went out
with the BRL UNIX System V emulation for 4.2BSD.  The correct types were
adopted by X3J11 and P1003; the SVID Issue 2, IEEE Std 1003.1, forthcoming
ANSI X3.159, and presumably all other current UNIX/C standards specify
the correct type.  SVR3.0 <signal.h> is correct.  Presumably Sun picked
up the correct type from one of these.

>After much thinking I have found no advantage to this change, and the
>big disadvantage that stable existing code now brreaks.

Implementations that permitted you to be sloppy about the void/int
function return distinction can continue to permit such sloppiness.
Presumably they use compatible linkage for both function return types.

>Now I'm faced with this problem:  How do I use signal() in such a way
>that my code is portable, without manually editing it for each
>implementation?   I need a way of having my code automatically use void
>or int as appropriate.

The correct signal handler return type is void no matter what <signal.h>
says.

There have been compilers (early 4BSD PCCs, for example) that couldn't
correctly handle pointers to functions returning void.  For that reason
and that reason only, it may behoove you to define a type sig_hdlr_ret_t
in your site's equivalent of <std.h> (i.e. a header used by all your
applications, that augments the standard C environment with things to
provide a uniform interface to implementation dependencies); set it to
int or void depending on how well the environment deals with this, and
code your signal handlers as returning sig_hdlr_ret_t.