Unsigned arithmetic in C++
up vote
11
down vote
favorite
I just observed a strange phenomenon when doing unsigned arithmetic. It's expected that b and -a have the same number 4294967286 due to wraparound, but the actual output for b and -a is -10 and 4294967286 respectively. Could anyone help give a hint?
#include <iostream>
int main() {
unsigned int a = 10;
int b = -a;
std::cout << b << ", " << -a << std::endl;
}
https://repl.it/repls/ExpertDrabOrganization
c++
asked Nov 20 at 8:10
Zhe Chen
1,42331528
add a comment |
up vote
11
down vote
favorite
I just observed a strange phenomenon when doing unsigned arithmetic. It's expected that b and -a have the same number 4294967286 due to wraparound, but the actual output for b and -a is -10 and 4294967286 respectively. Could anyone help give a hint?
#include <iostream>
int main() {
unsigned int a = 10;
int b = -a;
std::cout << b << ", " << -a << std::endl;
}
https://repl.it/repls/ExpertDrabOrganization
c++
asked Nov 20 at 8:10
Zhe Chen
1,42331528
2
Why do you expect that anintwould have the value 4294967286, which is much larger than the maximumint?
– molbdnilo
Nov 20 at 8:15
1
int b = -a;->unsigned int b = -a;
– Paul R
Nov 20 at 8:18
1
@molbdnilo My fault. I forgot thatboverflows, too.
– Zhe Chen
Nov 20 at 8:20
add a comment |
up vote
11
down vote
favorite
up vote
11
down vote
favorite
I just observed a strange phenomenon when doing unsigned arithmetic. It's expected that b and -a have the same number 4294967286 due to wraparound, but the actual output for b and -a is -10 and 4294967286 respectively. Could anyone help give a hint?
#include <iostream>
int main() {
unsigned int a = 10;
int b = -a;
std::cout << b << ", " << -a << std::endl;
}
https://repl.it/repls/ExpertDrabOrganization
c++
asked Nov 20 at 8:10
Zhe Chen
1,42331528
I just observed a strange phenomenon when doing unsigned arithmetic. It's expected that b and -a have the same number 4294967286 due to wraparound, but the actual output for b and -a is -10 and 4294967286 respectively. Could anyone help give a hint?
#include <iostream>
int main() {
unsigned int a = 10;
int b = -a;
std::cout << b << ", " << -a << std::endl;
}
https://repl.it/repls/ExpertDrabOrganization
c++
c++
asked Nov 20 at 8:10
Zhe Chen
1,42331528
asked Nov 20 at 8:10
Zhe Chen
1,42331528
edited Nov 20 at 8:14
asked Nov 20 at 8:10
Zhe Chen
1,42331528
asked Nov 20 at 8:10
Zhe Chen
1,42331528
asked Nov 20 at 8:10
Zhe Chen
1,42331528
1,42331528
2
Why do you expect that anintwould have the value 4294967286, which is much larger than the maximumint?
– molbdnilo
Nov 20 at 8:15
1
int b = -a;->unsigned int b = -a;
– Paul R
Nov 20 at 8:18
1
@molbdnilo My fault. I forgot thatboverflows, too.
– Zhe Chen
Nov 20 at 8:20
add a comment |
2
Why do you expect that anintwould have the value 4294967286, which is much larger than the maximumint?
– molbdnilo
Nov 20 at 8:15
1
int b = -a;->unsigned int b = -a;
– Paul R
Nov 20 at 8:18
1
@molbdnilo My fault. I forgot thatboverflows, too.
– Zhe Chen
Nov 20 at 8:20
2
2
Why do you expect that an
int would have the value 4294967286, which is much larger than the maximum int?– molbdnilo
Nov 20 at 8:15
Why do you expect that an
int would have the value 4294967286, which is much larger than the maximum int?– molbdnilo
Nov 20 at 8:15
1
1
int b = -a; -> unsigned int b = -a;– Paul R
Nov 20 at 8:18
int b = -a; -> unsigned int b = -a;– Paul R
Nov 20 at 8:18
1
1
@molbdnilo My fault. I forgot that
b overflows, too.– Zhe Chen
Nov 20 at 8:20
@molbdnilo My fault. I forgot that
b overflows, too.– Zhe Chen
Nov 20 at 8:20
add a comment |
1 Answer
1
active
oldest
votes
up vote
17
down vote
accepted
-a is evaluated in unsigned arithmetic, and will be a number larger than std::numeric_limits<int>::max(). The unary operator - when applied to an unsigned type acts more like a modulus operator.
Therefore the behaviour of your program is implementation defined due to an out-of-range assignment to an int.
edited Nov 20 at 13:23
Bakudan
13.3k84264
answered Nov 20 at 8:17
Bathsheba
173k27244366
3
implementation defined - I.e. look at the docs, and shout at your implementer if they don't do what they promise.
– StoryTeller
Nov 20 at 8:39
@StoryTeller: Since which flashy new standard?
– Bathsheba
Nov 20 at 8:40
1
@StoryTeller It was implementation-defined in C++03 too.
– Angew
Nov 20 at 8:52
2
@Angew - Interestingly enough, it's implementation defined in a C99 draft I have lying around. It would seem that a conversion was always with implementation defined semantics. Overflow in arithmetic with signed types is UB, however, wherever I checked. Curious.
– StoryTeller
Nov 20 at 9:03
1
gcc implementation defined behavior: The value is reduced module 2^N. So the same for clang. For MSVC this behavior is not ensured: docs.microsoft.com/en-us/cpp/c-language/…
– Oliv
Nov 20 at 9:44
|
show 3 more comments
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
17
down vote
accepted
-a is evaluated in unsigned arithmetic, and will be a number larger than std::numeric_limits<int>::max(). The unary operator - when applied to an unsigned type acts more like a modulus operator.
Therefore the behaviour of your program is implementation defined due to an out-of-range assignment to an int.
edited Nov 20 at 13:23
Bakudan
13.3k84264
answered Nov 20 at 8:17
Bathsheba
173k27244366
3
implementation defined - I.e. look at the docs, and shout at your implementer if they don't do what they promise.
– StoryTeller
Nov 20 at 8:39
@StoryTeller: Since which flashy new standard?
– Bathsheba
Nov 20 at 8:40
1
@StoryTeller It was implementation-defined in C++03 too.
– Angew
Nov 20 at 8:52
2
@Angew - Interestingly enough, it's implementation defined in a C99 draft I have lying around. It would seem that a conversion was always with implementation defined semantics. Overflow in arithmetic with signed types is UB, however, wherever I checked. Curious.
– StoryTeller
Nov 20 at 9:03
1
gcc implementation defined behavior: The value is reduced module 2^N. So the same for clang. For MSVC this behavior is not ensured: docs.microsoft.com/en-us/cpp/c-language/…
– Oliv
Nov 20 at 9:44
|
show 3 more comments
up vote
17
down vote
accepted
-a is evaluated in unsigned arithmetic, and will be a number larger than std::numeric_limits<int>::max(). The unary operator - when applied to an unsigned type acts more like a modulus operator.
Therefore the behaviour of your program is implementation defined due to an out-of-range assignment to an int.
edited Nov 20 at 13:23
Bakudan
13.3k84264
answered Nov 20 at 8:17
Bathsheba
173k27244366
3
implementation defined - I.e. look at the docs, and shout at your implementer if they don't do what they promise.
– StoryTeller
Nov 20 at 8:39
@StoryTeller: Since which flashy new standard?
– Bathsheba
Nov 20 at 8:40
1
@StoryTeller It was implementation-defined in C++03 too.
– Angew
Nov 20 at 8:52
2
@Angew - Interestingly enough, it's implementation defined in a C99 draft I have lying around. It would seem that a conversion was always with implementation defined semantics. Overflow in arithmetic with signed types is UB, however, wherever I checked. Curious.
– StoryTeller
Nov 20 at 9:03
1
gcc implementation defined behavior: The value is reduced module 2^N. So the same for clang. For MSVC this behavior is not ensured: docs.microsoft.com/en-us/cpp/c-language/…
– Oliv
Nov 20 at 9:44
|
show 3 more comments
up vote
17
down vote
accepted
up vote
17
down vote
accepted
-a is evaluated in unsigned arithmetic, and will be a number larger than std::numeric_limits<int>::max(). The unary operator - when applied to an unsigned type acts more like a modulus operator.
Therefore the behaviour of your program is implementation defined due to an out-of-range assignment to an int.
edited Nov 20 at 13:23
Bakudan
13.3k84264
answered Nov 20 at 8:17
Bathsheba
173k27244366
-a is evaluated in unsigned arithmetic, and will be a number larger than std::numeric_limits<int>::max(). The unary operator - when applied to an unsigned type acts more like a modulus operator.
Therefore the behaviour of your program is implementation defined due to an out-of-range assignment to an int.
edited Nov 20 at 13:23
Bakudan
13.3k84264
answered Nov 20 at 8:17
Bathsheba
173k27244366
edited Nov 20 at 13:23
Bakudan
13.3k84264
edited Nov 20 at 13:23
Bakudan
13.3k84264
edited Nov 20 at 13:23
Bakudan
13.3k84264
13.3k84264
answered Nov 20 at 8:17
Bathsheba
173k27244366
answered Nov 20 at 8:17
Bathsheba
173k27244366
answered Nov 20 at 8:17
Bathsheba
173k27244366
173k27244366
3
implementation defined - I.e. look at the docs, and shout at your implementer if they don't do what they promise.
– StoryTeller
Nov 20 at 8:39
@StoryTeller: Since which flashy new standard?
– Bathsheba
Nov 20 at 8:40
1
@StoryTeller It was implementation-defined in C++03 too.
– Angew
Nov 20 at 8:52
2
@Angew - Interestingly enough, it's implementation defined in a C99 draft I have lying around. It would seem that a conversion was always with implementation defined semantics. Overflow in arithmetic with signed types is UB, however, wherever I checked. Curious.
– StoryTeller
Nov 20 at 9:03
1
gcc implementation defined behavior: The value is reduced module 2^N. So the same for clang. For MSVC this behavior is not ensured: docs.microsoft.com/en-us/cpp/c-language/…
– Oliv
Nov 20 at 9:44
|
show 3 more comments
3
implementation defined - I.e. look at the docs, and shout at your implementer if they don't do what they promise.
– StoryTeller
Nov 20 at 8:39
@StoryTeller: Since which flashy new standard?
– Bathsheba
Nov 20 at 8:40
1
@StoryTeller It was implementation-defined in C++03 too.
– Angew
Nov 20 at 8:52
2
@Angew - Interestingly enough, it's implementation defined in a C99 draft I have lying around. It would seem that a conversion was always with implementation defined semantics. Overflow in arithmetic with signed types is UB, however, wherever I checked. Curious.
– StoryTeller
Nov 20 at 9:03
1
gcc implementation defined behavior: The value is reduced module 2^N. So the same for clang. For MSVC this behavior is not ensured: docs.microsoft.com/en-us/cpp/c-language/…
– Oliv
Nov 20 at 9:44
3
3
implementation defined - I.e. look at the docs, and shout at your implementer if they don't do what they promise.
– StoryTeller
Nov 20 at 8:39
implementation defined - I.e. look at the docs, and shout at your implementer if they don't do what they promise.
– StoryTeller
Nov 20 at 8:39
@StoryTeller: Since which flashy new standard?
– Bathsheba
Nov 20 at 8:40
@StoryTeller: Since which flashy new standard?
– Bathsheba
Nov 20 at 8:40
1
1
@StoryTeller It was implementation-defined in C++03 too.
– Angew
Nov 20 at 8:52
@StoryTeller It was implementation-defined in C++03 too.
– Angew
Nov 20 at 8:52
2
2
@Angew - Interestingly enough, it's implementation defined in a C99 draft I have lying around. It would seem that a conversion was always with implementation defined semantics. Overflow in arithmetic with signed types is UB, however, wherever I checked. Curious.
– StoryTeller
Nov 20 at 9:03
@Angew - Interestingly enough, it's implementation defined in a C99 draft I have lying around. It would seem that a conversion was always with implementation defined semantics. Overflow in arithmetic with signed types is UB, however, wherever I checked. Curious.
– StoryTeller
Nov 20 at 9:03
1
1
gcc implementation defined behavior: The value is reduced module 2^N. So the same for clang. For MSVC this behavior is not ensured: docs.microsoft.com/en-us/cpp/c-language/…
– Oliv
Nov 20 at 9:44
gcc implementation defined behavior: The value is reduced module 2^N. So the same for clang. For MSVC this behavior is not ensured: docs.microsoft.com/en-us/cpp/c-language/…
– Oliv
Nov 20 at 9:44
|
show 3 more comments
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53388686%2funsigned-arithmetic-in-c%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
Why do you expect that an
intwould have the value 4294967286, which is much larger than the maximumint?– molbdnilo
Nov 20 at 8:15
1
int b = -a;->unsigned int b = -a;– Paul R
Nov 20 at 8:18
1
@molbdnilo My fault. I forgot that
boverflows, too.– Zhe Chen
Nov 20 at 8:20