inc unsigned (whatever) beyond limit.

[.rhavin grobert]

when i do a.....
________________________________________________
unsigned int iTest; // lets asume 'int' = 32bit
iTest = 0xFFFFFFFF;
iTest++;
________________________________________________

does the std say something what shall happen now?
May i safely assume iTest is now 0 or is it CPU or sys-dependent?


TIA, ~.rhavin

 

[Zeppe]

when i do a.....
________________________________________________
unsigned int iTest; // lets asume 'int' = 32bit
iTest = 0xFFFFFFFF;
iTest++;
________________________________________________

does the std say something what shall happen now?
May i safely assume iTest is now 0 or is it CPU or sys-dependent?


TIA, ~.rhavin

the second one.

best, zeppe

 

[.rhavin grobert]

the second one.

best, zeppe

CPU-dependent? damn, that's the worst case!

 

[REH]

the second one.

best, zeppe

That is incorrect. Assuming unsigned int is 32-bits, result will
always be 0.

REH

 

[Maxim Yegorushkin]

the second one.

Wrong answer.

The C and C++ standards guarantee the wrapping for unsigned integer
types.

Here is a relevant quote from C99 6.2.5:

A computation involving unsigned operands can never 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 type.

 

[Erik Wikström]

[..]
The C and C++ standards guarantee the wrapping for unsigned integer
types.

Here is a relevant quote from C99 6.2.5:
[..]

Why C99? C++ has its own Standard, does it not?

For your pleasure:

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."

 

[Zeppe]

Wrong answer.

The C and C++ standards guarantee the wrapping for unsigned integer
types.

My bad. Actually, I know that piece, I just ignored the comment as a
compiler would do. So, the result IS sys-dependent, BUT if you assume
that all the systems in which that code will be compiled are going to be
32bit, then is safe to assume that iTest is going to be zero after the
increment.

Sorry about that.

Best wishes,

Zeppe

 

[.rhavin grobert]

How about this:

    unsigned i = UINT_MAX;
    i++;
    assert( i == 0 );

Actually it's that one:
________________________________

typedef unsigned __int64 QUAD;

class foo {
foo(): m_qSel(0) {};
public:
inline QUAD NextSelector() {return m_qSel++;};
private:
QUAD m_qSel;
};

 

[Michael]

when i do a.....
________________________________________________
unsigned int iTest; // lets asume 'int' = 32bit
iTest = 0xFFFFFFFF;
iTest++;
________________________________________________

does the std say something what shall happen now?
May i safely assume iTest is now 0 or is it CPU or sys-dependent?


TIA, ~.rhavin

It is now 0 because it is unsigned and int is 32 bits.
Unsigned integer 'overflow' is always safe.

 

[.rhavin grobert]

".rhavin grobert" <[email protected]> kirjutas:

On 21 Okt., 20:23, (e-mail address removed) (blargg) wrote: [...]

How about this:
    unsigned i = UINT_MAX;
    i++;
    assert( i == 0 );

Actually it's that one:
________________________________

typedef unsigned __int64 QUAD;

class foo {
  foo(): m_qSel(0) {};
public:
  inline QUAD NextSelector() {return m_qSel++;};
private:
  QUAD m_qSel;
};

And you are wondering what happens when this wraps over? Let's see,
assuming for example million increments in a second(*), this happens ...
in approx. 9000 years! It's really reassuring to know the behavior will
be well-defined!

Paavo

(*) and assuming unsigned __int64 is an implementation-defined unsigned
64-bit integer type following the same rules as standard types.

*sigh* humans!

;-)