avoid #ifdef SIGCONT/SIGTSTP

[Eric Gisin]

Interactive added definitions for SIGCONT, SIGSTOP, ... to <signal.h>
in release 2.2, and SCO added them to their UNIX.
However, Interactive definitions are different from SCO and System V rel 4.

If you conditionalize your code with #ifdef on one of the above
signal names, it will not generate portable (System V/386 rel 3.2)
binaries when compiled under Interactive UNIX rel 2.2.
The code generated by
	#ifdef SIGCONT
		signal(SIGCONT, handler);
	#endif
will have an invalid signal number when run on stock System V 3.2 systems
(including Interactive 2.0), and will be interpreted as signal(SIGSTOP,...)
on SCO UNIX. A SIGTSTP handler will become a SIGCONT handler on SCO UNIX.

It is better to use #ifdef _POSIX_JOB_CONTROL in portable applications.

If you want handlers for job control signals (to redraw prompts or the screen,
or save/restore tty state), you have to generate additional binaries
for Interactive 2.2, SCO UNIX, and everyone else who adds job control to System V rel 3.2.

On Interactive you can do this by compiling with -Xp (POSIX.1 universe).
This causes problems; a lot of code won't compile anymore.
Or you could use long, hairy #ifdefs to handle all the OS variations.

It looks like Interactive added job control handlers to libcurses.a (tstp.o).
Can someone report if binaries linked with -lcurses on Interactive 2.2 are
portable?

In general, if you use any of the POSIX.1 features of Interactive or SCO
(job control, termios, rename, sigaction, ...) your binaries are
non-portable. They will not run on other vendors UNIX, nor on earlier
releases from the same vendor.  The binary will either have illegal system
calls, or just strange signal behaviour.
[This last point (at least) should go in the FAQ list]