svn commit: r227369 - head/bin/sh

Jilles Tjoelker jilles at stack.nl
Mon Nov 21 23:51:05 UTC 2011


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


More information about the svn-src-head mailing list