CODEWITHSUNDEEP
c++standards
Etienne Vouga
Etienne Vouga

Reputation:

MSVC++: Strangeness with unsigned ints and overflow

I've got the following code:

#include <iostream>

using namespace std;

int main(int argc, char *argv[])
{
    string a = "a";
    for(unsigned int i=a.length()-1; i+1 >= 1; --i)
    {
        if(i >= a.length())
        {
            cerr << (signed int)i << "?" << endl;
            return 0;
        }
    }
}

If I compile in MSVC with full optimizations, the output I get is "-1?". If I compile in Debug mode (no optimizations), I get no output (expected.)

I thought the standard guaranteed that unsigned integers overflowed in a predictable way, so that when i = (unsigned int)(-1), i+1 = 0, and the loop condition i + 1 >= 1 fails. Instead, the test is somehow passing. Is this a compiler bug, or am I doing something undefined somewhere?

Upvotes: 8

Views: 378

Answers (4)

greyfade
greyfade

Reputation: 25647

ISO14882:2003, section 5, 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 (5.19), in which case the program is ill-formed.

(Emphasis mine.) So, yes, the behavior is undefined. The standard makes no guarantees of behavior in the case of integer over/underflow.

Edit: The standard seems slightly conflicted on the matter elsewhere.

Section 3.9.1.4 says:

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.

But section 4.7.2 and .3 says:

2) If the destination type is unsigned, the resulting value is the least unsigned integer congruent to the source integer (modulo 2 n where n is the number of bits used to represent the unsigned type). [Note: In a two’s complement representation, this conversion is conceptual and there is no change in the bit pattern (if there is no truncation). ]

3) If the destination type is signed, the value is unchanged if it can be represented in the destination type (and bit-field width); otherwise, the value is implementation-defined.

(Emphasis mine.)

Upvotes: 4

JZig
JZig

Reputation: 123

Yup, I just tested this on Visual Studio 2005, it definitely behaves differently in Debug and Release. I wonder if 2008 fixes it.

Interestingly it complained about your implicit cast from size_t (.length's result) to unsigned int, but has no problem generating bad code.

Upvotes: 0

Jonathan Leffler
Jonathan Leffler

Reputation: 753805

I'm not certain, but I think you are probably running foul of a bug.

I suspect the trouble is in how the compiler is treating the for control. I could imagine the optimizer doing:

for(unsigned int i=a.length()-1; i+1 >= 1; --i)   // As written

for (unsigned int i = a.length()-1; i >= 0; --i) // Noting 1 appears twice

for (unsigned int i = a.length()-1; ; --i)   // Because i >= 0 at all times

Whether that is what is happening is another matter, but it might be enough to confuse the optimizer.

You would probably be better off using a more standard loop formulation:

for (unsigned i = a.length()-1; i-- > 0; )

Upvotes: 1

Andrew Shepherd
Andrew Shepherd

Reputation: 45252

I remember having this problem in 2001. I'm amazed it's still there. Yes, this is a compiler bug.

The optimiser is seeing 

i + 1 >= 1;

Theoretically, we can optimise this by putting all of the constants on the same side:

i >= (1-1);

Because i is unsigned, it will always be greater than or equal to zero.

See this newsgroup discussion here.

Upvotes: 8

Related Questions