From owner-svn-src-head@FreeBSD.ORG Mon Feb 27 01:48:48 2012 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E229E106564A; Mon, 27 Feb 2012 01:48:48 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail15.syd.optusnet.com.au (mail15.syd.optusnet.com.au [211.29.132.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6152E8FC0A; Mon, 27 Feb 2012 01:48:47 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail15.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q1R1mhds008571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Feb 2012 12:48:45 +1100 Date: Mon, 27 Feb 2012 12:48:43 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Jilles Tjoelker In-Reply-To: <20120226232540.GA34962@stack.nl> Message-ID: <20120227123912.I2260@besplex.bde.org> References: <201202241235.q1OCZH2U059017@svn.freebsd.org> <20120225024051.C1150@besplex.bde.org> <20120224210141.GA3223@stack.nl> <20120225084319.P3207@besplex.bde.org> <20120226232540.GA34962@stack.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Bruce Evans Subject: Re: svn commit: r232108 - head/usr.bin/xargs X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 01:48:49 -0000 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