On Mon, 27 Feb 2012, Jilles Tjoelker wrote:
On Sat, Feb 25, 2012 at 09:10:04AM +1100, Bruce Evans wrote:
On Fri, 24 Feb 2012, Jilles Tjoelker wrote:
I don't think xargs should work around that bug, particularly not by
introducing unspecified behaviour (the value of WTERMSIG(x) when
!WIFSIGNALED(x)).
OK. So it needs to be disallowed in the kernel.
Hmm. The kernel allows 0 <= sig <= 128 (_SIG_MAXSIG). It also allows
signals 33..64 which do not have a documented meaning.
I wonder what will break if I change _SIG_MAXSIG to 126. This will
disallow all operations on signals 127 and 128 and change the sigacts
structure. Alternatively, the check in sys_kill() and friends could be
tightened.
I forgot about the extra one. 128 gives slightly more brokenness than
127 -- shells are confused by it, and turn it into $? = 0. Was the
old PR about #127 or #128 or both?
I think nothing should be using these signals, so nothing should break
if you change _SIG_MAXSIG to 126 and change the sigacts struct to use
a harder-coded 128.
Bruce
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
