eric@mks.com (Eric Gisin) (09/18/90)
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]