SunOS: 1; portability: 0
Conor P. Cahill
cpcahil at virtech.UUCP
Sat Sep 23 12:18:18 AEST 1989
In article <880 at cirrusl.UUCP>, dhesi at sun505.UUCP (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.
No, signal(2) now returns a pointer to a function returning void.
> After much thinking I have found no advantage to this change, and the
> big disadvantage that stable existing code now brreaks.
Since signal() returns the pointer to the old signal handler or signal
handling status, and a signal handler, being called asynchronously with
respect to the rest of the code in the program, does not "return" a value
the "type" of a signal handler should be void.
> 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.
How about cc arg "-DSIGNAL_TYPE=void" and using it as:
SIGNAL_TYPE (*signal())();
--
+-----------------------------------------------------------------------+
| Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 !
| Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 |
+-----------------------------------------------------------------------+
More information about the Comp.unix.questions
mailing list