3

Possible Duplicate:
C++ underflow and overflow

I have following code in c++:

int temp = std::numeric_limits<int>::max();
temp++;

Am I sure that after incrementation the result will always be <0?

Thanks

Community
  • 1
  • 1
user1332475
  • 115
  • 1
  • 6

2 Answers2

4

No, it's not guaranteed. C++03 has this to say in 5 Expressions, paragraph 5:

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, unless such an expression is a constant expression, in which case the program is ill-formed. [Note: most existing implementations of C + + ignore integer overflows].

Further, there is nothing in 5.7 Additive operators that modifies this behaviour. This is unchanged in C++11.

That's for signed types, which is what you asked about in your question.

If you're also interested in unsigned types, section 3.9.1 Fundamental types, paragraph 4 states:

Unsigned integers, declared unsigned, shall obey the laws of arithmetic modulo 2n where n is the number of bits in the value representation of that particular size of integer (see footnote 41).

Footnote 41: 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.

Community
  • 1
  • 1
paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
  • 1
    Aren't unsigned types guaranteed to wrap around? – Luchian Grigore Sep 05 '12 at 06:01
  • @veer that's why I'm asking, because I was pretty sure it was. – Luchian Grigore Sep 05 '12 at 06:02
  • There's nothing in that section that differentiates between signed and unsigned values. In any case, the question regarded `int`, which is signed. – paxdiablo Sep 05 '12 at 06:03
  • Unsigned types are guaranteed to wrap around. Why the C and C++ standards don't make the same guarantee for signed types is beyond me. – john Sep 05 '12 at 06:15
  • 1
    @john: Because the standards allow for three different representations of signed types. Mandating that it behave as if it the architecture used twos-complement would force implementations for other architectures to be inefficient. – Mike Seymour Sep 05 '12 at 06:24
  • @MikeSeymour I realise that is the reason, that anyone thinks that is a good reason is what is beyond me. I have never seen a machine that doesn't use two's complement. But because they existed in the past we all pay the penalty now in a lack specification in the C/C++ standards. Does anyone think this is a good situation? Since the current standard says UB, there is no reason that mandating two's complement could not have been introduced. – john Sep 05 '12 at 07:41
  • @john, We also have to put up with the fact that it's not guaranteed that a-z are contiguous characters, despite the fact the EBCDIC community is a relatively small one (USS on the mainframe). ISO take compatibility _very_ seriously. Having said that, at least EBCDIC is still around. The list of machines doing sign/magnitude and 1s complement all seem to come from decades ago. – paxdiablo Sep 05 '12 at 07:42
  • @paxdiablo Small is one thing, non-existent is another. – john Sep 05 '12 at 07:44
  • @john: Presumably, they didn't share your certainty that currently unfashionable architectures will never be used again, and didn't see any compelling reason to reduce portability for the sake of removing one of many sources of UB. But I can't speak for them; perhaps they only did it to annoy you. – Mike Seymour Sep 05 '12 at 08:16
  • I've asked whether there are any non-2s-compl environments in the wild here: http://stackoverflow.com/questions/12276957/does-anyone-know-of-any-non-twos-complement-implementations-of-c – paxdiablo Sep 05 '12 at 08:19
  • @MikeSeymour It is a bugbear of mine but I don't think it's a trivial issue. The general confusion over signed and unsigned types has been the source of at least one security issue in Windows code, http://archives.neohapsis.com/archives/fulldisclosure/2004-02/0806.html – john Sep 05 '12 at 20:30
3

No, overflow in signed integral types results in undefined behavior.

EDIT: In addition to paxdiablo's quote:

3.9.1.

Note 46) 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.

Luchian Grigore
  • 253,575
  • 64
  • 457
  • 625
  • You are indeed correct! §3.9.1¶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." – obataku Sep 05 '12 at 06:10