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