svn commit: r232108 - head/usr.bin/xargs

[Bruce Evans]

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