kern/19402: Signals 127 and 128 cannot be detected in wait4() interface

[Jilles Tjoelker]

The following reply was made to PR kern/19402; it has been noted by GNATS.

From: Jilles Tjoelker <jilles at stack.nl>
To: bug-followup at FreeBSD.org, netch at segfault.kiev.ua
Cc: bde at freebsd.org
Subject: Re: kern/19402: Signals 127 and 128 cannot be detected in wait4()
 interface
Date: Mon, 30 Apr 2012 00:46:19 +0200

 > [problems with signals 127 and 128]
 
 First, note that "clean" programs cannot use signals 127 and 128 because
 they do neither have a SIG* constant nor are in the range SIGRTMIN to
 SIGRTMAX. Therefore, I think it is inappropriate to make large changes
 to make them work. It suffices if wait4() and other interfaces cannot
 cause confusion.
 
 Because sh returns exit status 128+sig for signal sig, signal 128 cannot
 be represented in an 8-bit exit status and would have to be aliased to
 another signal if it is kept.
 
 The suggestion to modify wait4() ABI seems inappropriate for that
 reason.
 
 Another option is to modify the highest signal number accepted by
 interfaces (while leaving the size of sigset_t and the like unchanged).
 This effectively removes signals 127 and 128 from the system. One
 problem results when having posix_spawn() from an old libc reset all
 signals to default (by passing posix_spawnattr_setsigdefault() a
 sigfillset()'ed sigset_t and enabling the POSIX_SPAWN_SETSIGDEF flag in
 the posix_spawnattr_t). It will then attempt to set all signals from 1
 to 128 to the default action and fail the entire spawn if sigaction()
 fails. This could be allowed by having certain calls (such as
 sigaction() with SIG_DFL) return success without doing anything for
 signals 127 and 128. This is likely to get messy.
 
 Alternatively, the default action for signals 127 and 128 could be
 changed to ignore (like SIGCHLD, SIGURG and SIGINFO), so that no process
 may terminate because of them. Processes can still send the signals and
 set handlers for them. Apart from the obvious effect that the process
 will not terminate when it receives such a signal without handling or
 masking it, FreeBSD also discards ignored signals even when they are
 masked (POSIX permits this). This could lead to unexpected results if a
 process is using sigwait() or a similar function.
 
 Yet another approach would modify the wait4() system call, changing
 signals 127 and 128 to something that does not cause confusion. This
 seems ugly.
 
 -- 
 Jilles Tjoelker