From owner-svn-src-head@FreeBSD.ORG Mon Nov 21 23:51:05 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 360EE10657C8; Mon, 21 Nov 2011 23:51:05 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id C62768FC0A; Mon, 21 Nov 2011 23:51:04 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 255EE1DD633; Tue, 22 Nov 2011 00:51:02 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id F267F28468; Tue, 22 Nov 2011 00:51:01 +0100 (CET) Date: Tue, 22 Nov 2011 00:51:01 +0100 From: Jilles Tjoelker To: Bruce Evans Message-ID: <20111121235101.GA8012@stack.nl> References: <201111082354.pA8NsdhP055080@svn.freebsd.org> <20111109083545.GC1598@mole.fafoe.narf.at> <20111109203528.GA29992@stack.nl> <20111121181134.A882@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111121181134.A882@besplex.bde.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Stefan Farfeleder , 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: Mon, 21 Nov 2011 23:51:05 -0000 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: > % 6.3.1.3 Signed and unsigned integers > % ... > % [#3] Otherwise, the new type is signed and the value cannot > % be represented in it; the result is implementation-defined. > % J.3 Implementation-defined behavior > % ... > % J.3.5 Integers > % > % [#1] > % ... > % -- The result of converting an integer to a signed integer > % type when the value cannot be represented in an object > % of that type (6.3.1.3). > > n869.txt barely mentions signals, especially here. Its only literal > match for "signal raised" is in Annex H for LIA, which says that if > an arithmetic exception raises a signal, then the signal shall be > SIGFPE, and this is mainly for floating point. It has many more literal > matches for "exception raised", since Annex F for IEEE754 requires > exceptions to be raised a lot; these exceptions normally don't generate > signals. > > GCC documentation (gcc.info 4.5 Integers implementation) says this > > ] * `The result of, or the signal raised by, converting an integer to a > > ] signed integer type when the value cannot be represented in an > > ] object of that type (C90 6.2.1.2, C99 6.3.1.3).' > ", or the signal raised by, " in this seems to be a bug in gcc > documentation. The documentation of implementation-defined behaviour > shouldn't mention that specifed behaviour is implemented, at least > without distinguishing the part that is as specified. 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. > > ] 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. I think there should be some "loopholes" to do signed integer arithmetic with wraparound, not allowing the compiler to assume there is no overflow. 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. -- Jilles Tjoelker