By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,190 Members | 811 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,190 IT Pros & Developers. It's quick & easy.

overflow of unsigned int

P: n/a
Suppose

unsigned int size = UINT_MAX;

Now consider

++size;

After increment operator, size value becomes zero in

1) VC++ 2005 Express Edition on Intel Pentium D and
2) Redhat Enterprise Linux gcc on Intel Pentium D

Will it be possible to tell whether this behaviour(ie becoming 0) be
the same on all machines and all standard C compliant compilers. Is
this a question about overflow ? I am reading K & R second edition.
Are there any internet links that I should read material to know
more ?

Thanks

Mar 9 '07 #1
Share this Question
Share on Google+
3 Replies


P: n/a
su**************@yahoo.com, India said:
Suppose

unsigned int size = UINT_MAX;

Now consider

++size;

After increment operator, size value becomes zero in
....all conforming implementations.
>
1) VC++ 2005 Express Edition on Intel Pentium D and
2) Redhat Enterprise Linux gcc on Intel Pentium D

Will it be possible to tell whether this behaviour(ie becoming 0) be
the same on all machines and all standard C compliant compilers.
Yes.
Is this a question about overflow ?
No. Unsigned integer types cannot overflow. All unsigned integer
arithmetic is performed modulo one greater than the largest value that
the type can store.
I am reading K & R second edition.
Good.
Are there any internet links that I should read material to know
more ?
<http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdfis a draft
of the latest C Standard plus revisions. Also, you may like to consider
checking out some other relevant links about learning C, as listed at
<http://www.cpax.org.uk/prg/portable/c/resources.php>.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Mar 9 '07 #2

P: n/a
su**************@yahoo.com, India wrote:
Suppose

unsigned int size = UINT_MAX;

Now consider

++size;

After increment operator, size value becomes zero in

1) VC++ 2005 Express Edition on Intel Pentium D and
2) Redhat Enterprise Linux gcc on Intel Pentium D

Will it be possible to tell whether this behaviour(ie becoming 0) be
the same on all machines and all standard C compliant compilers.
Yes, it is consistent across all conformant C implementations.
Is this a question about overflow ?
No, the C standard ascribes modulo 2^n arithmetic for unsigned types,
which by definition, has no overflow. Rather it produces a ring with
wrap-around of the value. Overflow is defined only for signed integral
and floating point types.

Mar 9 '07 #3

P: n/a
Richard Heathfield wrote On 03/09/07 07:37,:
[...]
Unsigned integer types cannot overflow. [...]
This is literally true, but it seems to be a point of
confusion: the matter arises in c.l.c. again and again and
again. Perhaps we need a term to describe the non-overflow-
but-possibly-surprising thing that happens when unsigned
arithmetic operates on an expression whose "mathematical"
value is outside the type's range. "Discontinuity" doesn't
seem appropriate, but "wraparound" (in various forms) has
been used before and seems to convey the right meaning.
Richard's oft-repeated statement might be a little more
informative to the befuddled if it read

Unsigned integer types cannot overflow;
they wrap around.

My own preference would be to focus on the arithmetic
rather than on the type, and say

Unsigned arithmetic cannot overflow; it
wraps around.

.... but that's a minor stylistic point about which reasonable
people can disagree in amity.

(In the post I quoted, Richard goes on to describe
"wrap around" precisely, in terms of modular arithmetic.
That's still helpful, but perhaps "wrap around" would give
the confused reader an up-front handle for understanding.)

Thoughts?

--
Er*********@sun.com
Mar 9 '07 #4

This discussion thread is closed

Replies have been disabled for this discussion.