signed int overflow

[Andrew Koenig]

Is unsigned overflow defined in all cases? Where in the C++ standard does
it
say that?

Subclause 3.9.1, paragraph 4:
Unsigned integers, declared unsigned, shall obey the laws of arithmetic
modulo 2^n where n is the number of bits in the value representation of that
particular size of integer. [Footnote: This implies that unsigned arithmetic
does not overflow because a result that cannot be represented by the
resulting unsigned integer type is reduced modulo the number that is one
greater than the largest value that can be represented by the resulting
unsigned integer type.]

The situation with signed overflow is ridiculous. The standard should say
overflow is defined as if twos complement arithmetic was being performed.

Why? That would prohibit implementations from treating integer overflow as
an error.

 

[John Harrison]

Why? That would prohibit implementations from treating integer overflow as
an error.

They already are prevented from treating unsigned integer overflow as an
error.

john

 

[Andrew Koenig]

Okay let's say that Standard C++... allows... a program to crash should
you
cause a signed int to overflow.

It does.

Well... what the hell kind of implementation would allow this?! Even if
one
does exist, it would have been abandoned 17 years 6 months and 2 days ago.

The kind of implementation that would allow it is the kind of implementation
that would try to detect programmer errors rather than ignoring them.

Imagine it, boot up WinXP. Open a few documents, play minesweeper, CRASH
(Opps sorry, this computer is shit, it crashes if signed integers
overflow).

This kind of argument is often referred to as a "straw man." You take the
claims of the viewpoint you oppose, distort them to make them sound
ridiculous, then claim that they can't be right because they sound
ridiculous.

In practice, it is often far from clear whether it is worse for a program to
crash or to quietly give incorrect or nonsensical results.

I'm open to further discussion on this... but at the moment it looks like
I'm going to ignore the directive that signed int overflow is undefined
behaviour and thus that the program may crash. Come on, it's bullshit!

I don't think you're open to further discussion. At least you're not
behaving like you are.

 

[Andrew Koenig]

They already are prevented from treating unsigned integer overflow as an
error.

I don't understand your point. Are you suggesting that because unsigned
arithmetic is defined as being modulo 2^n, signed arithmetic should be
defined that way as well? If so, you will have to make a case for that
claim if you wish to convince me.

 

[Alf P. Steinbach]

* Andrew Koenig:

* John Harrison:

Why? That would prohibit implementations from treating integer overflow as
an error.

The current UB prevents programs from checking for error and from utilizing
the overflow behavior, in a formally portable manner.

That's far worse and far more concrete than the extremely marginal and
hypothetical possibility of some error-detecting implementation, which
AFAIK does not exist (if it had some utility, presumably it would exist).

So the argument about allowing an implementation to treat overflow as
error is a fallacy.

On the other hand, the thread in [comp.std.c++] showed that the arguments
in favor of standardization are not especially forceful.

And there the matter rests, I think (personally I agree with John, but nice-
to-have is not need-to-have, and standardizing existing practice would be
a break with the tradition in C++ standardization, wouldn't it?).


Cheers,

- Alf

 

[Rolf Magnus]

I don't understand your point. Are you suggesting that because unsigned
arithmetic is defined as being modulo 2^n, signed arithmetic should be
defined that way as well? If so, you will have to make a case for that
claim if you wish to convince me.

What about consistancy? Why treat them so differently? Can you actually name
any platform that simply does the modulo on unsigned integers and something
completely different and unreproducable on signed ones? I'd say they should
either be both undefined or both not undefined. Actually, I think they
should both be implementation-defined.

 

[assaarpa]

What about consistancy? Why treat them so differently? Can you actually
name

any platform that simply does the modulo on unsigned integers and something
completely different and unreproducable on signed ones? I'd say they should
either be both undefined or both not undefined. Actually, I think they
should both be implementation-defined.

Speaking of which, anyone knows if someone has ever compiled a chart of
somekind (doesn't matter if out-of-date by 10 years where some
implementation specific things would have been mapped? -> loading
www.google.com ... okay, let's re-phrase.. anyone knows any GOOD maps of
this sort?

 

[Ron Natalie]

What about consistancy? Why treat them so differently? Can you actually name
any platform that simply does the modulo on unsigned integers and something
completely different and unreproducable on signed ones? I'd say they should
either be both undefined or both not undefined. Actually, I think they
should both be implementation-defined.

Certainly, I can. Any one's complement machine most likely does a non-modulo
answer on integer roll over. Further, I have worked on machines (Gould SEL) that
trapped integer overflows.

 

[Alf P. Steinbach]

* Ron Natalie:

Certainly, I can. Any one's complement machine most likely does a non-modulo
answer on integer roll over.

Have you an example of a one's complement machine in use, for which a C++
implementation exists?

Further, I have worked on machines (Gould SEL) that trapped integer overflows.

I just Googled that and found e.g. <url: http://213.130.56.75/gould.html>
<quote>
Real-time programs should not crash. Halting hardware and man-in-the-loop
simulations damages equipment and hurts people. Gould-SEL run-time systems are
therefore tolerant of division by zero (It is assumed that the result can be
ignored)
</quote>

Given that Gould SEL runtime systems tolerate even division by zero it seems
amazing that they do not tolerate signed integer overflow; comment?

Anyway, to be conforming a C++ compiler for Gould SEL cannot trap overflow on
unsigned ints, and it's no hassle to implement signed ints in terms of
unsigned ints (addition and subtraction map directly to unsigned operations
with no extra processing, multiplication and division requires a small check).

So was your experience with a C++ compiler (if so which), or another language?

Remember that behavior in a given language is not necessarily a constraint
imposed by the machine, and as mentioned above, even with silly constraints
imposed by the machine a language implementation can easily work around it.

 

[Rolf Magnus]

Certainly, I can.

Why don't you do it then?

Any one's complement machine most likely does a non-modulo answer on
integer roll over. Further, I have worked on machines (Gould
SEL) that trapped integer overflows.

And it did so only for signed ones and not unsigned?

 

[Alf P. Steinbach]

* Greg Comeau -> JKop:

Playing devil advocate:
BTW, would you care if instead of dates, you were programming
the systems at the bank where your bank account is, and those
values were your paycheck? Or even sticking with dates,
the dates your pension should kick it and direct deposit
your account? This program will be portable (sic)
(I'm not necessarily presenting a solution here (yet),
mostly just raising more situations.)

The question you raise is important (it's the same question raised by
Andrew Koenig, and I suspect the same misconception that UB is in some
way a Good Thing in this context).

With UB there's no portable and efficient way to do error checking.

With defined behavior it's trivial (well, uhm, trivial and trivial,
a few folks including me, ahem, managed to get it wrong, but at least
it's trivial for most cases, and when you know general solution... ;-) ).

 

[Greg Comeau]

* Greg Comeau -> JKop:

The question you raise is important (it's the same question raised by
Andrew Koenig, and I suspect the same misconception that UB is in some
way a Good Thing in this context).

Well, it certainly allows for flexibility.

With UB there's no portable and efficient way to do error checking.

This may be so for UB, but...

With defined behavior it's trivial (well, uhm, trivial and trivial,
a few folks including me, ahem, managed to get it wrong, but at least
it's trivial for most cases, and when you know general solution... ;-) ).

.... that does not mean the error checking can't be done through
other means, if necessary.

 

[Rolf Magnus]

* Greg Comeau -> JKop:

The question you raise is important (it's the same question raised by
Andrew Koenig, and I suspect the same misconception that UB is in some
way a Good Thing in this context).

With UB there's no portable and efficient way to do error checking.

There is no portable and efficent way anyway, since lots of systems don't
support that in hardware.

With defined behavior it's trivial (well, uhm, trivial and trivial,
a few folks including me, ahem, managed to get it wrong, but at least
it's trivial for most cases, and when you know general solution... ;-) ).

It is? Could you give an example?

 

[JKop]

There is no portable and efficent way anyway, since lots
of systems

don't support that in hardware.

Sure there is! Hijack the operators. If you see that it's
about to go past its limit, send it back to zero, or just
freeze it at its maximum value.

Simple stuff, if you're bothered writing it...


-JKop

 

[Alf P. Steinbach]

* Rolf Magnus:

There is no portable and efficent way anyway, since lots of systems don't
support that in hardware.

That is incorrect.

All systems that support arithmetic and conditionals (which they must to
be Turing complete) support error checking.

It is? Could you give an example?

The simplest example is the addition of two non-negative numbers. With 2's
complement signed integer you have overflow if and only if the result is
negative. The rest was discussed in the [comp.std.c++] thread about this.

 

[Ron Natalie]

Simple stuff, if you're bothered writing it...

Nobody said it was hard....the issue is how inefficient do you want to make the
language.

 

[Tom Widmer]

* Rolf Magnus:

That is incorrect.

All systems that support arithmetic and conditionals (which they must to
be Turing complete) support error checking.

But if the CPU traps when it detects signed integer overflow (gcc has
an option for this, I can certainly imagine CPUs designed for mission
critical applications doing this)? On such a machine, you'd have to do
the arithmetic in 64-bits and then check for 32-bit overflow.

It is? Could you give an example?

The simplest example is the addition of two non-negative numbers. With 2's
complement signed integer you have overflow if and only if the result is
negative. The rest was discussed in the [comp.std.c++] thread about this.

If your system documents that it does this, and you only intend to
port to other machines that also do this, then what's the problem? The
code isn't 100% portable, but it is fine for your needs.

Tom

 

[Alf P. Steinbach]

* Tom Widmer:

All systems that support arithmetic and conditionals (which they must to
be Turing complete) support error checking.

But if the CPU traps when it detects signed integer overflow (gcc has
an option for this, I can certainly imagine CPUs designed for mission
critical applications doing this)? On such a machine, you'd have to do
the arithmetic in 64-bits and then check for 32-bit overflow.
No.

With defined behavior it's trivial (well, uhm, trivial and trivial,
a few folks including me, ahem, managed to get it wrong, but at least
it's trivial for most cases, and when you know general solution... ;-) ).

It is? Could you give an example?

The simplest example is the addition of two non-negative numbers. With 2's
complement signed integer you have overflow if and only if the result is
negative. The rest was discussed in the [comp.std.c++] thread about this.

If your system documents that it does this, and you only intend to
port to other machines that also do this,

hypothetical


then what's the problem?
UB


The code isn't 100% portable, but it is fine for your needs.

no

 

[Tom Widmer]

* Tom Widmer:

No.

You have two values,
int a = blah;
int b = blah2;

How do you portably, efficiently and simply check whether "a + b"
would overflow or not? (this is a genuine question - I don't know
whether it is possible or not). I can think of inefficient techiques,
for sure.

With defined behavior it's trivial (well, uhm, trivial and trivial,
a few folks including me, ahem, managed to get it wrong, but at least
it's trivial for most cases, and when you know general solution... ;-) ).

It is? Could you give an example?

The simplest example is the addition of two non-negative numbers. With 2's
complement signed integer you have overflow if and only if the result is
negative. The rest was discussed in the [comp.std.c++] thread about this.

If your system documents that it does this, and you only intend to
port to other machines that also do this,

hypothetical


then what's the problem?

UB

And indeed it is UB. On many platforms, you get 2s complement
wraparound, but on some you get a CPU trap, and on some you get 1s
complement results. Requiring anything else in the language makes
*all* integer arithmetic inefficient, at least on platforms which
don't naturally do the mandated behaviour (whatever you want that to
be).

no

What, precisely, do you want the standard to say then, if not UB? In
what way isn't it sufficient for your needs?

Tom

 

[Alf P. Steinbach]

* Tom Widmer:

And indeed it is UB. On many platforms, you get 2s complement
wraparound, but on some you get a CPU trap, and on some you get 1s
complement results. Requiring anything else in the language makes
*all* integer arithmetic inefficient, at least on platforms which
don't naturally do the mandated behaviour (whatever you want that to
be).

AFAIK the above is incorrect.

No-one has been able to come up with examples of C++ compilers that do
anything but 2's complement.

If you have even a single such example please give it.