Topic: addition overflow; UB or not?


Author: Martin Bonner <martinfrompi@yahoo.co.uk>
Date: Wed, 8 Dec 2010 10:45:57 CST
Raw View
On Dec 8, 7:31 am, restor <akrze...@gmail.com> wrote:
> Hi,
> In latest C++ draft, 5:4 says "If during the evaluation of an
> expression, the result is not mathematically defined or not in the
> range of
> representable values for its type, the behavior is undefined."
> On the other hand, in 1.9:9 the note says, in a long example, that
> some operations cannot be regrouped because this would not preserve an
> overflow exception.
> Is it not a contradiction?

No.  Consider
    int i, j, k;
    // i large and negative, j and k large and positive.
    return (i+j) + k;

The programmer is responsible for ensuring that i+j does not overflow,
and that k plus that sum does not overflow.  The programmer does /not/
need to ensure that j+k doesn't overflow.  The compiler can only
rewrite the return statement as
   return i + (j+k);
if the actual behaviour on overflow is such that the result is
identical.

Note that this matters on processors using saturated arithmetic (where
the behaviour on overflow is to replace the result with the maximum
value), and processors that raise a signal when overflow occurs, and
on processors using sign and magnitude representation.


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]





Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@googlemail.com>
Date: Wed, 8 Dec 2010 10:45:37 CST
Raw View
On 12/8/2010 08:31, restor wrote:
>
> Hi,
> In latest C++ draft, 5:4 says "If during the evaluation of an
> expression, the result is not mathematically defined or not in the
> range of
> representable values for its type, the behavior is undefined."
> On the other hand, in 1.9:9 the note says, in a long example, that
> some operations cannot be regrouped because this would not preserve an
> overflow exception.
> Is it not a contradiction?

This is no contradiction. The example is referring to potential
rearrangements of the order of evaluation of code by the compiler. All
what 1.9 p. 9 says is that a compiler cannot rearrange code such that
the result would be undefined behaviour that would *not* occur, if the
original code would be well-defined.

There is no requirement that overflow "exceptions" occur (they are not
really exceptions in the C++ sense) and a note can to refer to anything
that is defined or not defined in the standard. In this sense an
overflow exception is undefined behaviour.

HTH & Greetings from Bremen,

Daniel Kr   gler


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]





Author: restor <akrzemi1@gmail.com>
Date: Wed, 8 Dec 2010 01:31:36 CST
Raw View
Hi,
In latest C++ draft, 5:4 says "If during the evaluation of an
expression, the result is not mathematically defined or not in the
range of
representable values for its type, the behavior is undefined."
On the other hand, in 1.9:9 the note says, in a long example, that
some operations cannot be regrouped because this would not preserve an
overflow exception.
Is it not a contradiction?

Regards,
&rzej


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]