Date: Mon, 27 Feb 2012 12:48:43 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Jilles Tjoelker <jilles@stack.nl> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Bruce Evans <brde@optusnet.com.au> Subject: Re: svn commit: r232108 - head/usr.bin/xargs Message-ID: <20120227123912.I2260@besplex.bde.org> In-Reply-To: <20120226232540.GA34962@stack.nl> References: <201202241235.q1OCZH2U059017@svn.freebsd.org> <20120225024051.C1150@besplex.bde.org> <20120224210141.GA3223@stack.nl> <20120225084319.P3207@besplex.bde.org> <20120226232540.GA34962@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120227123912.I2260>