From owner-svn-src-head@FreeBSD.ORG Thu Nov 24 04:25:56 2011 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 A06C5106564A; Thu, 24 Nov 2011 04:25:56 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id 3A79A8FC18; Thu, 24 Nov 2011 04:25:55 +0000 (UTC) Received: from c211-28-227-231.carlnfd1.nsw.optusnet.com.au (c211-28-227-231.carlnfd1.nsw.optusnet.com.au [211.28.227.231]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id pAO4Pfml013615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Nov 2011 15:25:52 +1100 Date: Thu, 24 Nov 2011 15:25:41 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Jilles Tjoelker In-Reply-To: <20111121235101.GA8012@stack.nl> Message-ID: <20111124145950.N1102@besplex.bde.org> References: <201111082354.pA8NsdhP055080@svn.freebsd.org> <20111109083545.GC1598@mole.fafoe.narf.at> <20111109203528.GA29992@stack.nl> <20111121181134.A882@besplex.bde.org> <20111121235101.GA8012@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, Stefan Farfeleder , Bruce Evans , src-committers@FreeBSD.org Subject: Re: svn commit: r227369 - head/bin/sh 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: Thu, 24 Nov 2011 04:25:56 -0000 On Tue, 22 Nov 2011, Jilles Tjoelker wrote: > On Mon, Nov 21, 2011 at 06:29:06PM +1100, Bruce Evans wrote: >> On Wed, 9 Nov 2011, Jilles Tjoelker wrote: >>> On Wed, Nov 09, 2011 at 09:35:51AM +0100, Stefan Farfeleder wrote: >>>> Isn't the behaviour undefined too when you convert an out-of-range >>>> uintmax_t value back into an intmax_t value? > >>> The result is implementation-defined or an implementation-defined signal >>> is raised. > >> C doesn't allow any signal, at least in C90 and n869.txt draft C99: > ... > The possibility of a signal is mentioned in C99TC2 draft n1124 and > remains in C1x draft n1548. The documentation in 'info gcc' is > consistent with that. I wonder why they (C standards) broke that. Though the implementation may prefer to raising a signal, C90 (and C99-non-draft?) doesn't allow that, and it is a large change to allow one. >>> ] For conversion to a type of width N, the value is reduced modulo >>> ] 2^N to be within range of the type; no signal is raised. > >>> which is exactly what we need. > >> Of course, a correct implementation would give a random result, so that >> no one depends on implementation-defined behaviour. > > That would be a non-practical implementation, as it would be both slower > and run fewer existing applications. It's point is to run fewer existing applications -- the broken ones :-). This would not necessarily be slower. The hardware might want to or be able to trap (at no cost unless there is overflow). Then the implementation can convert the trap to a random result, instead of rasing a signal. The hardware might be 1's complement, but not trap. Then the fast version would give a non-random result, but not what you want. The slow version to give the 2's complement result that you want could probably give a random result instead. Now it is apparently allowed to trap instead. A trap is of course better for running fewer existing applications. Old ones won't have a trap handler and will just crash. > I think there should be some "loopholes" to do signed integer arithmetic > with wraparound, not allowing the compiler to assume there is no > overflow. Something like FENV_ACCESS pragmas would be useful. But these are still not supported by gcc-4.2 or clang. > While POSIX leaves the behaviour on overflow and division by zero in > shell arithmetic undefined as with C arithmetic (although it mentions > the possibility of converting to floating point in case of overflow), I > prefer that sh(1) not crash. It should avoid overflow and produce its own implementation-defined result, without depending on implementation-defined or undefined behaviour in C. This is easier when someone else is doing it :-). Bruce