Date: Tue, 22 Nov 2011 00:51:01 +0100 From: Jilles Tjoelker <jilles@stack.nl> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Stefan Farfeleder <stefanf@freebsd.org>, src-committers@freebsd.org Subject: Re: svn commit: r227369 - head/bin/sh Message-ID: <20111121235101.GA8012@stack.nl> In-Reply-To: <20111121181134.A882@besplex.bde.org> References: <201111082354.pA8NsdhP055080@svn.freebsd.org> <20111109083545.GC1598@mole.fafoe.narf.at> <20111109203528.GA29992@stack.nl> <20111121181134.A882@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111121235101.GA8012>