throopw@xyzzy.UUCP (Wayne A. Throop) (04/07/88)
> henry@utzoo.uucp (Henry Spencer) > I'm only gonna say this one more time: just about the only fully portable > thing a signal handler can do is set a flag. Not just any flag, but a > flag of type sig_atomic_t, defined in <signal.h> in an ANSI C implementation. This reminds me of an issue I'd thought of before. If the only portable thing that receipt of a signal can provoke is the setting of a flag, why doesn't ANSI specify signal catching routines where the user can specify SIG_DFL, SIG_IGN, or the address of a flag of type sig_atomic_t? The current non-portable, more general routines could be kept as "common extensions", but the more portable thing would be required. -- Everyone can be taught to scilpt: Michelangelo would have had to be taught how not to. So it is with the great programmers. --- Alan J. Perlis -- Wayne Throop <the-known-world>!mcnc!rti!xyzzy!throopw
henry@utzoo.uucp (Henry Spencer) (04/09/88)
> ... If the only portable > thing that receipt of a signal can provoke is the setting of a flag, why > doesn't ANSI specify signal catching routines where the user can specify > SIG_DFL, SIG_IGN, or the address of a flag of type sig_atomic_t? Somehow this doesn't seem worth a new invention. C has no shortage of tools that one has to use wisely if one wants the programs to be portable (or, for that matter, to work); signal() is just one more. -- "Noalias must go. This is | Henry Spencer @ U of Toronto Zoology non-negotiable." --DMR | {allegra,ihnp4,decvax,utai}!utzoo!henry