what's the point using unsigned int in C?
I thought that unsigned int could store only integers >= 0.
But I tried assigning a negative to an unsigned int, nothing special happened.
It seems like it stored the value with no problem.
So what is the difference between signed and unsigned int, and what's the point if it can store any value anyway?
c int unsigned signed
|
show 3 more comments
I thought that unsigned int could store only integers >= 0.
But I tried assigning a negative to an unsigned int, nothing special happened.
It seems like it stored the value with no problem.
So what is the difference between signed and unsigned int, and what's the point if it can store any value anyway?
c int unsigned signed
2
Tip: By default, most C compilers are very reticent with providing unsolicited warnings. Ask it to speak up, and you will be astounded.
– Deduplicator
Dec 22 '18 at 22:57
5
"stored the value with no problem": there was a problem.
– DYZ
Dec 22 '18 at 22:58
Duplicate answer???: stackoverflow.com/questions/5169692/…
– Hayden
Dec 22 '18 at 22:59
1
Try this:int main(){ unsigned int a = -1; if( 2U < a ){ printf("2 < '-1'n"); }}
– datenwolf
Dec 22 '18 at 23:04
1
If you present the code by which you purport to show that an unsigned integer stores a negative number, we will point out to you where it relies on undefined behavior, or else simply does not show what you claim.
– John Bollinger
Dec 22 '18 at 23:42
|
show 3 more comments
I thought that unsigned int could store only integers >= 0.
But I tried assigning a negative to an unsigned int, nothing special happened.
It seems like it stored the value with no problem.
So what is the difference between signed and unsigned int, and what's the point if it can store any value anyway?
c int unsigned signed
I thought that unsigned int could store only integers >= 0.
But I tried assigning a negative to an unsigned int, nothing special happened.
It seems like it stored the value with no problem.
So what is the difference between signed and unsigned int, and what's the point if it can store any value anyway?
c int unsigned signed
c int unsigned signed
asked Dec 22 '18 at 22:54
Danny
442
442
2
Tip: By default, most C compilers are very reticent with providing unsolicited warnings. Ask it to speak up, and you will be astounded.
– Deduplicator
Dec 22 '18 at 22:57
5
"stored the value with no problem": there was a problem.
– DYZ
Dec 22 '18 at 22:58
Duplicate answer???: stackoverflow.com/questions/5169692/…
– Hayden
Dec 22 '18 at 22:59
1
Try this:int main(){ unsigned int a = -1; if( 2U < a ){ printf("2 < '-1'n"); }}
– datenwolf
Dec 22 '18 at 23:04
1
If you present the code by which you purport to show that an unsigned integer stores a negative number, we will point out to you where it relies on undefined behavior, or else simply does not show what you claim.
– John Bollinger
Dec 22 '18 at 23:42
|
show 3 more comments
2
Tip: By default, most C compilers are very reticent with providing unsolicited warnings. Ask it to speak up, and you will be astounded.
– Deduplicator
Dec 22 '18 at 22:57
5
"stored the value with no problem": there was a problem.
– DYZ
Dec 22 '18 at 22:58
Duplicate answer???: stackoverflow.com/questions/5169692/…
– Hayden
Dec 22 '18 at 22:59
1
Try this:int main(){ unsigned int a = -1; if( 2U < a ){ printf("2 < '-1'n"); }}
– datenwolf
Dec 22 '18 at 23:04
1
If you present the code by which you purport to show that an unsigned integer stores a negative number, we will point out to you where it relies on undefined behavior, or else simply does not show what you claim.
– John Bollinger
Dec 22 '18 at 23:42
2
2
Tip: By default, most C compilers are very reticent with providing unsolicited warnings. Ask it to speak up, and you will be astounded.
– Deduplicator
Dec 22 '18 at 22:57
Tip: By default, most C compilers are very reticent with providing unsolicited warnings. Ask it to speak up, and you will be astounded.
– Deduplicator
Dec 22 '18 at 22:57
5
5
"stored the value with no problem": there was a problem.
– DYZ
Dec 22 '18 at 22:58
"stored the value with no problem": there was a problem.
– DYZ
Dec 22 '18 at 22:58
Duplicate answer???: stackoverflow.com/questions/5169692/…
– Hayden
Dec 22 '18 at 22:59
Duplicate answer???: stackoverflow.com/questions/5169692/…
– Hayden
Dec 22 '18 at 22:59
1
1
Try this:
int main(){ unsigned int a = -1; if( 2U < a ){ printf("2 < '-1'n"); }}
– datenwolf
Dec 22 '18 at 23:04
Try this:
int main(){ unsigned int a = -1; if( 2U < a ){ printf("2 < '-1'n"); }}
– datenwolf
Dec 22 '18 at 23:04
1
1
If you present the code by which you purport to show that an unsigned integer stores a negative number, we will point out to you where it relies on undefined behavior, or else simply does not show what you claim.
– John Bollinger
Dec 22 '18 at 23:42
If you present the code by which you purport to show that an unsigned integer stores a negative number, we will point out to you where it relies on undefined behavior, or else simply does not show what you claim.
– John Bollinger
Dec 22 '18 at 23:42
|
show 3 more comments
5 Answers
5
active
oldest
votes
A statement like
unsigned int t = -1;
printf("%u", t);
is completely legal and well defined in C. Negative values, when assigned to an unsigned integral type, get implicitly converted (cf. for example, this online C standard draft):
6.3.1.3 Signed and unsigned integers
(2) Otherwise, if the new type is unsigned, the value is converted by
repeatedly adding or subtracting one more than the maximum value that
can be represented in the new type until the value is in the range of
the new type.
The output of above program is an unsigned value, i.e.
4294967295
So you can assign "negative" values to unsigned integral types, yet the result is not a negative value in its actual sense. This is particularly relevant when you compare unsigned integral values to negative values. Consider, for example, the following two loops:
int i = 10;
while (--i >= 0) { // 10 iterations
printf("i: %dn", i);
}
unsigned int u = 10;
while (--u >= 0) { // endless loop; warning provided.
printf("u: %un", u);
}
The first will finish after 10 iterations, whereas the second will never end: Unsigned integral values cannot become negative, so u >= 0
is always true.
add a comment |
You are correct that unsigned int
can only store integers >= 0. (Of course there is an upper limit too, and that upper limit depends on your architecture and is defined as UINT_MAX
in limits.h).
By assigning an signed int
value to an unsigned int
, you are invoking an implicit type conversion. The C language has some very precise rules about how this happens. Whenever possible, the compiler attempts to preserve the value whenever possible. Take this for instance:
int x = 5;
unsigned int y;
y = x;
The above code also does a type conversion, but since the value "5" is representable in both signed and unsigned integer ranges, the value can be preserved, so y
will also have a value of 5.
Now consider:
x = -5;
y = x;
Specifically in this case you are assigning a value that is not within the representable range of unsigned int
, and therefore the compiler must convert the value to something within range. The C standard dictates that the value 1 + UINT_MAX
will be added to the value until it is within range of unsigned int
. On most systems these days, UINT_MAX
is defined as 4294967925 (2^32 - 1), so the value of y
will actually be 4294967921 (or 0xFFFFFFFB in hex).
It is important to note that on twos-complement machines (nearly ubiquitous these days) the binary representations of a signed int
value of -5 is also 0xFFFFFFFB, but that is not required. The C standard allows for and supports machines that utilize different integer encodings, therefore portable code should never assume that the binary representation will be preserved after an implicit conversion such as this.
Hope this helps!
add a comment |
The point of using unsigned int in C is that:
- It gives you more range for positive values (at least 32,767 for signed vs at least 65,535 for unsigned)
- It gives you the ability to use the number for masking and avoid undefined behavior while bit-shifting the number
- It lets the compiler do the checking for you that you are not assigning improper values to the number (if you know it's supposed to be unsigned) which is what would have happened in your case had you compiled with warnings turned on.
3
@Fureeish, 2s complement is a convention for representing signed numbers. By definition, then, representations of unsigned types do not use it. And per C, representations of unsigned numbers do not have a sign bit. On the other hand, that does not give a larger range of numbers, or more numbers, but rather a different range of numbers, and more positive ones.
– John Bollinger
Dec 22 '18 at 23:40
1
Only answer that mentioned undefined bit-shift behavior in signed integers.
– Fred
Dec 22 '18 at 23:47
@JohnBollinger Fine point on "and more positive ones". The positive range of an unsigned type likeunsigned long
is allowed to be the same. Example:ULONG_MAX == LONG_MAX
, even thoughULONG_MAX/2 == LONG_MAX
is far far more common. I have not seen a platform employ this archaic feature for years, as it implies a padded unsigned type, and certainly never will see again.
– chux
Dec 23 '18 at 5:42
That's the first time I've heard of such an implementation, @chux. Interesting. I see that the standard allows it, but only if the range of the signed type is larger than the minimum required range for that type. But as it relates to the question at hand, even an unsigned type whose maximum representable value is not greater than that of the corresponding signed type enjoys some guarantees about its behavior that the corresponding signed type does not have (as I know you are aware).
– John Bollinger
Dec 23 '18 at 14:17
1
@JohnBollinger The singular occurrence I experienced was a wider than 32-bit type that was effectively some signedintN_t
and a (N-1)-bit unsigned as simply the "sign" bit was a padding bit. It had to do with the processor natively supporting*,/
of the signed, but not unsigned. Today, such a model would find too much push-back from the user community and given we do not see it today implies the Darwin pressure relegated that to the computer graveyard. So even though allowed, not a practical concern, like a unicorn 26-bit float
– chux
Dec 23 '18 at 14:35
add a comment |
One important point is that overflowing a signed integer is undefined behaviour, whereas unsigned integers are defined to wrap around. In fact that is what is happening when you assign a negative value to one: it simply wraps around until the value is in range.
While this wrap-around behaviour of unsigned types means it is indeed perfectly valid to assign negative values to them, converting them back to signed types is not as well-defined (at best it is implementation-defined, at worst undefined behaviour, depending on how you do it). And while it maybe even be true that on many common platforms the signed and unsigned integers are internally the same, the intended meaning of the value matters for comparisons, conversions (such as to floating point), as well as for compiler optimisation.
In summary, you should use an unsigned type when you need well-defined wrap-around semantics for over- and underflow, and/or you need to represent positive integers greater than the maximum of the corresponding (or largest suitable) signed type. Technically you could avoid signed types in most cases by implementing negative numbers on top of unsigned types (after all, you could simply choose to interpret certain bit patterns as negative numbers), but… why, when the language offers this service "for free". The only real problem with signed integers in C is having to watch out for overflow, but in return you may get better optimisation.
add a comment |
Unsigneds have 1) higher maximums and 2) defined, wraparound overflow.
If with infinite precision
(unxigned_c = unsigned_a + unsinged_b) >= UINT_MAX
then unsigned_c
will get reduced modulo UINT_MAX+1
:
#include <limits.h>
#include <stdio.h>
int main()
{
printf("%un", UINT_MAX+1); //prints 0
printf("%un", UINT_MAX+2); //prints 1
printf("%un", UINT_MAX+3); //prints 2
}
A a similar thing is happening with you storing signed values into an unsigned.
In this case 6.3.1.3p2 applies -- UINT_MAX+1
is conceptually added to the value).
With signed types, on the other hand, overflow is undefined, which means if you allow it to happen, your program is no longer well formed and the standard makes no guarantees about its behavior. Compilers exploit this for optimization by assuming it will never happen.
For example, if you compile
#include <limits.h>
#include <stdio.h>
__attribute__((noinline,noclone)) //or skip the attr & define it in another tu
_Bool a_plus1_gt_b(int a, int b) { return a + 1 > b; }
int main()
{
printf("%dn", a_plus1_gt_b(INT_MAX,0)); //0
printf("%dn", INT_MAX+1); //1
}
on gcc with -O3
, it'll very likely print
1
-2147483648
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
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%2f53899902%2fwhats-the-point-using-unsigned-int-in-c%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
A statement like
unsigned int t = -1;
printf("%u", t);
is completely legal and well defined in C. Negative values, when assigned to an unsigned integral type, get implicitly converted (cf. for example, this online C standard draft):
6.3.1.3 Signed and unsigned integers
(2) Otherwise, if the new type is unsigned, the value is converted by
repeatedly adding or subtracting one more than the maximum value that
can be represented in the new type until the value is in the range of
the new type.
The output of above program is an unsigned value, i.e.
4294967295
So you can assign "negative" values to unsigned integral types, yet the result is not a negative value in its actual sense. This is particularly relevant when you compare unsigned integral values to negative values. Consider, for example, the following two loops:
int i = 10;
while (--i >= 0) { // 10 iterations
printf("i: %dn", i);
}
unsigned int u = 10;
while (--u >= 0) { // endless loop; warning provided.
printf("u: %un", u);
}
The first will finish after 10 iterations, whereas the second will never end: Unsigned integral values cannot become negative, so u >= 0
is always true.
add a comment |
A statement like
unsigned int t = -1;
printf("%u", t);
is completely legal and well defined in C. Negative values, when assigned to an unsigned integral type, get implicitly converted (cf. for example, this online C standard draft):
6.3.1.3 Signed and unsigned integers
(2) Otherwise, if the new type is unsigned, the value is converted by
repeatedly adding or subtracting one more than the maximum value that
can be represented in the new type until the value is in the range of
the new type.
The output of above program is an unsigned value, i.e.
4294967295
So you can assign "negative" values to unsigned integral types, yet the result is not a negative value in its actual sense. This is particularly relevant when you compare unsigned integral values to negative values. Consider, for example, the following two loops:
int i = 10;
while (--i >= 0) { // 10 iterations
printf("i: %dn", i);
}
unsigned int u = 10;
while (--u >= 0) { // endless loop; warning provided.
printf("u: %un", u);
}
The first will finish after 10 iterations, whereas the second will never end: Unsigned integral values cannot become negative, so u >= 0
is always true.
add a comment |
A statement like
unsigned int t = -1;
printf("%u", t);
is completely legal and well defined in C. Negative values, when assigned to an unsigned integral type, get implicitly converted (cf. for example, this online C standard draft):
6.3.1.3 Signed and unsigned integers
(2) Otherwise, if the new type is unsigned, the value is converted by
repeatedly adding or subtracting one more than the maximum value that
can be represented in the new type until the value is in the range of
the new type.
The output of above program is an unsigned value, i.e.
4294967295
So you can assign "negative" values to unsigned integral types, yet the result is not a negative value in its actual sense. This is particularly relevant when you compare unsigned integral values to negative values. Consider, for example, the following two loops:
int i = 10;
while (--i >= 0) { // 10 iterations
printf("i: %dn", i);
}
unsigned int u = 10;
while (--u >= 0) { // endless loop; warning provided.
printf("u: %un", u);
}
The first will finish after 10 iterations, whereas the second will never end: Unsigned integral values cannot become negative, so u >= 0
is always true.
A statement like
unsigned int t = -1;
printf("%u", t);
is completely legal and well defined in C. Negative values, when assigned to an unsigned integral type, get implicitly converted (cf. for example, this online C standard draft):
6.3.1.3 Signed and unsigned integers
(2) Otherwise, if the new type is unsigned, the value is converted by
repeatedly adding or subtracting one more than the maximum value that
can be represented in the new type until the value is in the range of
the new type.
The output of above program is an unsigned value, i.e.
4294967295
So you can assign "negative" values to unsigned integral types, yet the result is not a negative value in its actual sense. This is particularly relevant when you compare unsigned integral values to negative values. Consider, for example, the following two loops:
int i = 10;
while (--i >= 0) { // 10 iterations
printf("i: %dn", i);
}
unsigned int u = 10;
while (--u >= 0) { // endless loop; warning provided.
printf("u: %un", u);
}
The first will finish after 10 iterations, whereas the second will never end: Unsigned integral values cannot become negative, so u >= 0
is always true.
edited Dec 22 '18 at 23:18
answered Dec 22 '18 at 23:03
Stephan Lechner
26.1k21839
26.1k21839
add a comment |
add a comment |
You are correct that unsigned int
can only store integers >= 0. (Of course there is an upper limit too, and that upper limit depends on your architecture and is defined as UINT_MAX
in limits.h).
By assigning an signed int
value to an unsigned int
, you are invoking an implicit type conversion. The C language has some very precise rules about how this happens. Whenever possible, the compiler attempts to preserve the value whenever possible. Take this for instance:
int x = 5;
unsigned int y;
y = x;
The above code also does a type conversion, but since the value "5" is representable in both signed and unsigned integer ranges, the value can be preserved, so y
will also have a value of 5.
Now consider:
x = -5;
y = x;
Specifically in this case you are assigning a value that is not within the representable range of unsigned int
, and therefore the compiler must convert the value to something within range. The C standard dictates that the value 1 + UINT_MAX
will be added to the value until it is within range of unsigned int
. On most systems these days, UINT_MAX
is defined as 4294967925 (2^32 - 1), so the value of y
will actually be 4294967921 (or 0xFFFFFFFB in hex).
It is important to note that on twos-complement machines (nearly ubiquitous these days) the binary representations of a signed int
value of -5 is also 0xFFFFFFFB, but that is not required. The C standard allows for and supports machines that utilize different integer encodings, therefore portable code should never assume that the binary representation will be preserved after an implicit conversion such as this.
Hope this helps!
add a comment |
You are correct that unsigned int
can only store integers >= 0. (Of course there is an upper limit too, and that upper limit depends on your architecture and is defined as UINT_MAX
in limits.h).
By assigning an signed int
value to an unsigned int
, you are invoking an implicit type conversion. The C language has some very precise rules about how this happens. Whenever possible, the compiler attempts to preserve the value whenever possible. Take this for instance:
int x = 5;
unsigned int y;
y = x;
The above code also does a type conversion, but since the value "5" is representable in both signed and unsigned integer ranges, the value can be preserved, so y
will also have a value of 5.
Now consider:
x = -5;
y = x;
Specifically in this case you are assigning a value that is not within the representable range of unsigned int
, and therefore the compiler must convert the value to something within range. The C standard dictates that the value 1 + UINT_MAX
will be added to the value until it is within range of unsigned int
. On most systems these days, UINT_MAX
is defined as 4294967925 (2^32 - 1), so the value of y
will actually be 4294967921 (or 0xFFFFFFFB in hex).
It is important to note that on twos-complement machines (nearly ubiquitous these days) the binary representations of a signed int
value of -5 is also 0xFFFFFFFB, but that is not required. The C standard allows for and supports machines that utilize different integer encodings, therefore portable code should never assume that the binary representation will be preserved after an implicit conversion such as this.
Hope this helps!
add a comment |
You are correct that unsigned int
can only store integers >= 0. (Of course there is an upper limit too, and that upper limit depends on your architecture and is defined as UINT_MAX
in limits.h).
By assigning an signed int
value to an unsigned int
, you are invoking an implicit type conversion. The C language has some very precise rules about how this happens. Whenever possible, the compiler attempts to preserve the value whenever possible. Take this for instance:
int x = 5;
unsigned int y;
y = x;
The above code also does a type conversion, but since the value "5" is representable in both signed and unsigned integer ranges, the value can be preserved, so y
will also have a value of 5.
Now consider:
x = -5;
y = x;
Specifically in this case you are assigning a value that is not within the representable range of unsigned int
, and therefore the compiler must convert the value to something within range. The C standard dictates that the value 1 + UINT_MAX
will be added to the value until it is within range of unsigned int
. On most systems these days, UINT_MAX
is defined as 4294967925 (2^32 - 1), so the value of y
will actually be 4294967921 (or 0xFFFFFFFB in hex).
It is important to note that on twos-complement machines (nearly ubiquitous these days) the binary representations of a signed int
value of -5 is also 0xFFFFFFFB, but that is not required. The C standard allows for and supports machines that utilize different integer encodings, therefore portable code should never assume that the binary representation will be preserved after an implicit conversion such as this.
Hope this helps!
You are correct that unsigned int
can only store integers >= 0. (Of course there is an upper limit too, and that upper limit depends on your architecture and is defined as UINT_MAX
in limits.h).
By assigning an signed int
value to an unsigned int
, you are invoking an implicit type conversion. The C language has some very precise rules about how this happens. Whenever possible, the compiler attempts to preserve the value whenever possible. Take this for instance:
int x = 5;
unsigned int y;
y = x;
The above code also does a type conversion, but since the value "5" is representable in both signed and unsigned integer ranges, the value can be preserved, so y
will also have a value of 5.
Now consider:
x = -5;
y = x;
Specifically in this case you are assigning a value that is not within the representable range of unsigned int
, and therefore the compiler must convert the value to something within range. The C standard dictates that the value 1 + UINT_MAX
will be added to the value until it is within range of unsigned int
. On most systems these days, UINT_MAX
is defined as 4294967925 (2^32 - 1), so the value of y
will actually be 4294967921 (or 0xFFFFFFFB in hex).
It is important to note that on twos-complement machines (nearly ubiquitous these days) the binary representations of a signed int
value of -5 is also 0xFFFFFFFB, but that is not required. The C standard allows for and supports machines that utilize different integer encodings, therefore portable code should never assume that the binary representation will be preserved after an implicit conversion such as this.
Hope this helps!
answered Dec 22 '18 at 23:13
Joe Hickey
1584
1584
add a comment |
add a comment |
The point of using unsigned int in C is that:
- It gives you more range for positive values (at least 32,767 for signed vs at least 65,535 for unsigned)
- It gives you the ability to use the number for masking and avoid undefined behavior while bit-shifting the number
- It lets the compiler do the checking for you that you are not assigning improper values to the number (if you know it's supposed to be unsigned) which is what would have happened in your case had you compiled with warnings turned on.
3
@Fureeish, 2s complement is a convention for representing signed numbers. By definition, then, representations of unsigned types do not use it. And per C, representations of unsigned numbers do not have a sign bit. On the other hand, that does not give a larger range of numbers, or more numbers, but rather a different range of numbers, and more positive ones.
– John Bollinger
Dec 22 '18 at 23:40
1
Only answer that mentioned undefined bit-shift behavior in signed integers.
– Fred
Dec 22 '18 at 23:47
@JohnBollinger Fine point on "and more positive ones". The positive range of an unsigned type likeunsigned long
is allowed to be the same. Example:ULONG_MAX == LONG_MAX
, even thoughULONG_MAX/2 == LONG_MAX
is far far more common. I have not seen a platform employ this archaic feature for years, as it implies a padded unsigned type, and certainly never will see again.
– chux
Dec 23 '18 at 5:42
That's the first time I've heard of such an implementation, @chux. Interesting. I see that the standard allows it, but only if the range of the signed type is larger than the minimum required range for that type. But as it relates to the question at hand, even an unsigned type whose maximum representable value is not greater than that of the corresponding signed type enjoys some guarantees about its behavior that the corresponding signed type does not have (as I know you are aware).
– John Bollinger
Dec 23 '18 at 14:17
1
@JohnBollinger The singular occurrence I experienced was a wider than 32-bit type that was effectively some signedintN_t
and a (N-1)-bit unsigned as simply the "sign" bit was a padding bit. It had to do with the processor natively supporting*,/
of the signed, but not unsigned. Today, such a model would find too much push-back from the user community and given we do not see it today implies the Darwin pressure relegated that to the computer graveyard. So even though allowed, not a practical concern, like a unicorn 26-bit float
– chux
Dec 23 '18 at 14:35
add a comment |
The point of using unsigned int in C is that:
- It gives you more range for positive values (at least 32,767 for signed vs at least 65,535 for unsigned)
- It gives you the ability to use the number for masking and avoid undefined behavior while bit-shifting the number
- It lets the compiler do the checking for you that you are not assigning improper values to the number (if you know it's supposed to be unsigned) which is what would have happened in your case had you compiled with warnings turned on.
3
@Fureeish, 2s complement is a convention for representing signed numbers. By definition, then, representations of unsigned types do not use it. And per C, representations of unsigned numbers do not have a sign bit. On the other hand, that does not give a larger range of numbers, or more numbers, but rather a different range of numbers, and more positive ones.
– John Bollinger
Dec 22 '18 at 23:40
1
Only answer that mentioned undefined bit-shift behavior in signed integers.
– Fred
Dec 22 '18 at 23:47
@JohnBollinger Fine point on "and more positive ones". The positive range of an unsigned type likeunsigned long
is allowed to be the same. Example:ULONG_MAX == LONG_MAX
, even thoughULONG_MAX/2 == LONG_MAX
is far far more common. I have not seen a platform employ this archaic feature for years, as it implies a padded unsigned type, and certainly never will see again.
– chux
Dec 23 '18 at 5:42
That's the first time I've heard of such an implementation, @chux. Interesting. I see that the standard allows it, but only if the range of the signed type is larger than the minimum required range for that type. But as it relates to the question at hand, even an unsigned type whose maximum representable value is not greater than that of the corresponding signed type enjoys some guarantees about its behavior that the corresponding signed type does not have (as I know you are aware).
– John Bollinger
Dec 23 '18 at 14:17
1
@JohnBollinger The singular occurrence I experienced was a wider than 32-bit type that was effectively some signedintN_t
and a (N-1)-bit unsigned as simply the "sign" bit was a padding bit. It had to do with the processor natively supporting*,/
of the signed, but not unsigned. Today, such a model would find too much push-back from the user community and given we do not see it today implies the Darwin pressure relegated that to the computer graveyard. So even though allowed, not a practical concern, like a unicorn 26-bit float
– chux
Dec 23 '18 at 14:35
add a comment |
The point of using unsigned int in C is that:
- It gives you more range for positive values (at least 32,767 for signed vs at least 65,535 for unsigned)
- It gives you the ability to use the number for masking and avoid undefined behavior while bit-shifting the number
- It lets the compiler do the checking for you that you are not assigning improper values to the number (if you know it's supposed to be unsigned) which is what would have happened in your case had you compiled with warnings turned on.
The point of using unsigned int in C is that:
- It gives you more range for positive values (at least 32,767 for signed vs at least 65,535 for unsigned)
- It gives you the ability to use the number for masking and avoid undefined behavior while bit-shifting the number
- It lets the compiler do the checking for you that you are not assigning improper values to the number (if you know it's supposed to be unsigned) which is what would have happened in your case had you compiled with warnings turned on.
edited Dec 22 '18 at 23:41
answered Dec 22 '18 at 23:13
mnistic
7,1061821
7,1061821
3
@Fureeish, 2s complement is a convention for representing signed numbers. By definition, then, representations of unsigned types do not use it. And per C, representations of unsigned numbers do not have a sign bit. On the other hand, that does not give a larger range of numbers, or more numbers, but rather a different range of numbers, and more positive ones.
– John Bollinger
Dec 22 '18 at 23:40
1
Only answer that mentioned undefined bit-shift behavior in signed integers.
– Fred
Dec 22 '18 at 23:47
@JohnBollinger Fine point on "and more positive ones". The positive range of an unsigned type likeunsigned long
is allowed to be the same. Example:ULONG_MAX == LONG_MAX
, even thoughULONG_MAX/2 == LONG_MAX
is far far more common. I have not seen a platform employ this archaic feature for years, as it implies a padded unsigned type, and certainly never will see again.
– chux
Dec 23 '18 at 5:42
That's the first time I've heard of such an implementation, @chux. Interesting. I see that the standard allows it, but only if the range of the signed type is larger than the minimum required range for that type. But as it relates to the question at hand, even an unsigned type whose maximum representable value is not greater than that of the corresponding signed type enjoys some guarantees about its behavior that the corresponding signed type does not have (as I know you are aware).
– John Bollinger
Dec 23 '18 at 14:17
1
@JohnBollinger The singular occurrence I experienced was a wider than 32-bit type that was effectively some signedintN_t
and a (N-1)-bit unsigned as simply the "sign" bit was a padding bit. It had to do with the processor natively supporting*,/
of the signed, but not unsigned. Today, such a model would find too much push-back from the user community and given we do not see it today implies the Darwin pressure relegated that to the computer graveyard. So even though allowed, not a practical concern, like a unicorn 26-bit float
– chux
Dec 23 '18 at 14:35
add a comment |
3
@Fureeish, 2s complement is a convention for representing signed numbers. By definition, then, representations of unsigned types do not use it. And per C, representations of unsigned numbers do not have a sign bit. On the other hand, that does not give a larger range of numbers, or more numbers, but rather a different range of numbers, and more positive ones.
– John Bollinger
Dec 22 '18 at 23:40
1
Only answer that mentioned undefined bit-shift behavior in signed integers.
– Fred
Dec 22 '18 at 23:47
@JohnBollinger Fine point on "and more positive ones". The positive range of an unsigned type likeunsigned long
is allowed to be the same. Example:ULONG_MAX == LONG_MAX
, even thoughULONG_MAX/2 == LONG_MAX
is far far more common. I have not seen a platform employ this archaic feature for years, as it implies a padded unsigned type, and certainly never will see again.
– chux
Dec 23 '18 at 5:42
That's the first time I've heard of such an implementation, @chux. Interesting. I see that the standard allows it, but only if the range of the signed type is larger than the minimum required range for that type. But as it relates to the question at hand, even an unsigned type whose maximum representable value is not greater than that of the corresponding signed type enjoys some guarantees about its behavior that the corresponding signed type does not have (as I know you are aware).
– John Bollinger
Dec 23 '18 at 14:17
1
@JohnBollinger The singular occurrence I experienced was a wider than 32-bit type that was effectively some signedintN_t
and a (N-1)-bit unsigned as simply the "sign" bit was a padding bit. It had to do with the processor natively supporting*,/
of the signed, but not unsigned. Today, such a model would find too much push-back from the user community and given we do not see it today implies the Darwin pressure relegated that to the computer graveyard. So even though allowed, not a practical concern, like a unicorn 26-bit float
– chux
Dec 23 '18 at 14:35
3
3
@Fureeish, 2s complement is a convention for representing signed numbers. By definition, then, representations of unsigned types do not use it. And per C, representations of unsigned numbers do not have a sign bit. On the other hand, that does not give a larger range of numbers, or more numbers, but rather a different range of numbers, and more positive ones.
– John Bollinger
Dec 22 '18 at 23:40
@Fureeish, 2s complement is a convention for representing signed numbers. By definition, then, representations of unsigned types do not use it. And per C, representations of unsigned numbers do not have a sign bit. On the other hand, that does not give a larger range of numbers, or more numbers, but rather a different range of numbers, and more positive ones.
– John Bollinger
Dec 22 '18 at 23:40
1
1
Only answer that mentioned undefined bit-shift behavior in signed integers.
– Fred
Dec 22 '18 at 23:47
Only answer that mentioned undefined bit-shift behavior in signed integers.
– Fred
Dec 22 '18 at 23:47
@JohnBollinger Fine point on "and more positive ones". The positive range of an unsigned type like
unsigned long
is allowed to be the same. Example: ULONG_MAX == LONG_MAX
, even though ULONG_MAX/2 == LONG_MAX
is far far more common. I have not seen a platform employ this archaic feature for years, as it implies a padded unsigned type, and certainly never will see again.– chux
Dec 23 '18 at 5:42
@JohnBollinger Fine point on "and more positive ones". The positive range of an unsigned type like
unsigned long
is allowed to be the same. Example: ULONG_MAX == LONG_MAX
, even though ULONG_MAX/2 == LONG_MAX
is far far more common. I have not seen a platform employ this archaic feature for years, as it implies a padded unsigned type, and certainly never will see again.– chux
Dec 23 '18 at 5:42
That's the first time I've heard of such an implementation, @chux. Interesting. I see that the standard allows it, but only if the range of the signed type is larger than the minimum required range for that type. But as it relates to the question at hand, even an unsigned type whose maximum representable value is not greater than that of the corresponding signed type enjoys some guarantees about its behavior that the corresponding signed type does not have (as I know you are aware).
– John Bollinger
Dec 23 '18 at 14:17
That's the first time I've heard of such an implementation, @chux. Interesting. I see that the standard allows it, but only if the range of the signed type is larger than the minimum required range for that type. But as it relates to the question at hand, even an unsigned type whose maximum representable value is not greater than that of the corresponding signed type enjoys some guarantees about its behavior that the corresponding signed type does not have (as I know you are aware).
– John Bollinger
Dec 23 '18 at 14:17
1
1
@JohnBollinger The singular occurrence I experienced was a wider than 32-bit type that was effectively some signed
intN_t
and a (N-1)-bit unsigned as simply the "sign" bit was a padding bit. It had to do with the processor natively supporting *,/
of the signed, but not unsigned. Today, such a model would find too much push-back from the user community and given we do not see it today implies the Darwin pressure relegated that to the computer graveyard. So even though allowed, not a practical concern, like a unicorn 26-bit float– chux
Dec 23 '18 at 14:35
@JohnBollinger The singular occurrence I experienced was a wider than 32-bit type that was effectively some signed
intN_t
and a (N-1)-bit unsigned as simply the "sign" bit was a padding bit. It had to do with the processor natively supporting *,/
of the signed, but not unsigned. Today, such a model would find too much push-back from the user community and given we do not see it today implies the Darwin pressure relegated that to the computer graveyard. So even though allowed, not a practical concern, like a unicorn 26-bit float– chux
Dec 23 '18 at 14:35
add a comment |
One important point is that overflowing a signed integer is undefined behaviour, whereas unsigned integers are defined to wrap around. In fact that is what is happening when you assign a negative value to one: it simply wraps around until the value is in range.
While this wrap-around behaviour of unsigned types means it is indeed perfectly valid to assign negative values to them, converting them back to signed types is not as well-defined (at best it is implementation-defined, at worst undefined behaviour, depending on how you do it). And while it maybe even be true that on many common platforms the signed and unsigned integers are internally the same, the intended meaning of the value matters for comparisons, conversions (such as to floating point), as well as for compiler optimisation.
In summary, you should use an unsigned type when you need well-defined wrap-around semantics for over- and underflow, and/or you need to represent positive integers greater than the maximum of the corresponding (or largest suitable) signed type. Technically you could avoid signed types in most cases by implementing negative numbers on top of unsigned types (after all, you could simply choose to interpret certain bit patterns as negative numbers), but… why, when the language offers this service "for free". The only real problem with signed integers in C is having to watch out for overflow, but in return you may get better optimisation.
add a comment |
One important point is that overflowing a signed integer is undefined behaviour, whereas unsigned integers are defined to wrap around. In fact that is what is happening when you assign a negative value to one: it simply wraps around until the value is in range.
While this wrap-around behaviour of unsigned types means it is indeed perfectly valid to assign negative values to them, converting them back to signed types is not as well-defined (at best it is implementation-defined, at worst undefined behaviour, depending on how you do it). And while it maybe even be true that on many common platforms the signed and unsigned integers are internally the same, the intended meaning of the value matters for comparisons, conversions (such as to floating point), as well as for compiler optimisation.
In summary, you should use an unsigned type when you need well-defined wrap-around semantics for over- and underflow, and/or you need to represent positive integers greater than the maximum of the corresponding (or largest suitable) signed type. Technically you could avoid signed types in most cases by implementing negative numbers on top of unsigned types (after all, you could simply choose to interpret certain bit patterns as negative numbers), but… why, when the language offers this service "for free". The only real problem with signed integers in C is having to watch out for overflow, but in return you may get better optimisation.
add a comment |
One important point is that overflowing a signed integer is undefined behaviour, whereas unsigned integers are defined to wrap around. In fact that is what is happening when you assign a negative value to one: it simply wraps around until the value is in range.
While this wrap-around behaviour of unsigned types means it is indeed perfectly valid to assign negative values to them, converting them back to signed types is not as well-defined (at best it is implementation-defined, at worst undefined behaviour, depending on how you do it). And while it maybe even be true that on many common platforms the signed and unsigned integers are internally the same, the intended meaning of the value matters for comparisons, conversions (such as to floating point), as well as for compiler optimisation.
In summary, you should use an unsigned type when you need well-defined wrap-around semantics for over- and underflow, and/or you need to represent positive integers greater than the maximum of the corresponding (or largest suitable) signed type. Technically you could avoid signed types in most cases by implementing negative numbers on top of unsigned types (after all, you could simply choose to interpret certain bit patterns as negative numbers), but… why, when the language offers this service "for free". The only real problem with signed integers in C is having to watch out for overflow, but in return you may get better optimisation.
One important point is that overflowing a signed integer is undefined behaviour, whereas unsigned integers are defined to wrap around. In fact that is what is happening when you assign a negative value to one: it simply wraps around until the value is in range.
While this wrap-around behaviour of unsigned types means it is indeed perfectly valid to assign negative values to them, converting them back to signed types is not as well-defined (at best it is implementation-defined, at worst undefined behaviour, depending on how you do it). And while it maybe even be true that on many common platforms the signed and unsigned integers are internally the same, the intended meaning of the value matters for comparisons, conversions (such as to floating point), as well as for compiler optimisation.
In summary, you should use an unsigned type when you need well-defined wrap-around semantics for over- and underflow, and/or you need to represent positive integers greater than the maximum of the corresponding (or largest suitable) signed type. Technically you could avoid signed types in most cases by implementing negative numbers on top of unsigned types (after all, you could simply choose to interpret certain bit patterns as negative numbers), but… why, when the language offers this service "for free". The only real problem with signed integers in C is having to watch out for overflow, but in return you may get better optimisation.
edited Dec 23 '18 at 10:31
answered Dec 22 '18 at 23:21
Arkku
30k44866
30k44866
add a comment |
add a comment |
Unsigneds have 1) higher maximums and 2) defined, wraparound overflow.
If with infinite precision
(unxigned_c = unsigned_a + unsinged_b) >= UINT_MAX
then unsigned_c
will get reduced modulo UINT_MAX+1
:
#include <limits.h>
#include <stdio.h>
int main()
{
printf("%un", UINT_MAX+1); //prints 0
printf("%un", UINT_MAX+2); //prints 1
printf("%un", UINT_MAX+3); //prints 2
}
A a similar thing is happening with you storing signed values into an unsigned.
In this case 6.3.1.3p2 applies -- UINT_MAX+1
is conceptually added to the value).
With signed types, on the other hand, overflow is undefined, which means if you allow it to happen, your program is no longer well formed and the standard makes no guarantees about its behavior. Compilers exploit this for optimization by assuming it will never happen.
For example, if you compile
#include <limits.h>
#include <stdio.h>
__attribute__((noinline,noclone)) //or skip the attr & define it in another tu
_Bool a_plus1_gt_b(int a, int b) { return a + 1 > b; }
int main()
{
printf("%dn", a_plus1_gt_b(INT_MAX,0)); //0
printf("%dn", INT_MAX+1); //1
}
on gcc with -O3
, it'll very likely print
1
-2147483648
add a comment |
Unsigneds have 1) higher maximums and 2) defined, wraparound overflow.
If with infinite precision
(unxigned_c = unsigned_a + unsinged_b) >= UINT_MAX
then unsigned_c
will get reduced modulo UINT_MAX+1
:
#include <limits.h>
#include <stdio.h>
int main()
{
printf("%un", UINT_MAX+1); //prints 0
printf("%un", UINT_MAX+2); //prints 1
printf("%un", UINT_MAX+3); //prints 2
}
A a similar thing is happening with you storing signed values into an unsigned.
In this case 6.3.1.3p2 applies -- UINT_MAX+1
is conceptually added to the value).
With signed types, on the other hand, overflow is undefined, which means if you allow it to happen, your program is no longer well formed and the standard makes no guarantees about its behavior. Compilers exploit this for optimization by assuming it will never happen.
For example, if you compile
#include <limits.h>
#include <stdio.h>
__attribute__((noinline,noclone)) //or skip the attr & define it in another tu
_Bool a_plus1_gt_b(int a, int b) { return a + 1 > b; }
int main()
{
printf("%dn", a_plus1_gt_b(INT_MAX,0)); //0
printf("%dn", INT_MAX+1); //1
}
on gcc with -O3
, it'll very likely print
1
-2147483648
add a comment |
Unsigneds have 1) higher maximums and 2) defined, wraparound overflow.
If with infinite precision
(unxigned_c = unsigned_a + unsinged_b) >= UINT_MAX
then unsigned_c
will get reduced modulo UINT_MAX+1
:
#include <limits.h>
#include <stdio.h>
int main()
{
printf("%un", UINT_MAX+1); //prints 0
printf("%un", UINT_MAX+2); //prints 1
printf("%un", UINT_MAX+3); //prints 2
}
A a similar thing is happening with you storing signed values into an unsigned.
In this case 6.3.1.3p2 applies -- UINT_MAX+1
is conceptually added to the value).
With signed types, on the other hand, overflow is undefined, which means if you allow it to happen, your program is no longer well formed and the standard makes no guarantees about its behavior. Compilers exploit this for optimization by assuming it will never happen.
For example, if you compile
#include <limits.h>
#include <stdio.h>
__attribute__((noinline,noclone)) //or skip the attr & define it in another tu
_Bool a_plus1_gt_b(int a, int b) { return a + 1 > b; }
int main()
{
printf("%dn", a_plus1_gt_b(INT_MAX,0)); //0
printf("%dn", INT_MAX+1); //1
}
on gcc with -O3
, it'll very likely print
1
-2147483648
Unsigneds have 1) higher maximums and 2) defined, wraparound overflow.
If with infinite precision
(unxigned_c = unsigned_a + unsinged_b) >= UINT_MAX
then unsigned_c
will get reduced modulo UINT_MAX+1
:
#include <limits.h>
#include <stdio.h>
int main()
{
printf("%un", UINT_MAX+1); //prints 0
printf("%un", UINT_MAX+2); //prints 1
printf("%un", UINT_MAX+3); //prints 2
}
A a similar thing is happening with you storing signed values into an unsigned.
In this case 6.3.1.3p2 applies -- UINT_MAX+1
is conceptually added to the value).
With signed types, on the other hand, overflow is undefined, which means if you allow it to happen, your program is no longer well formed and the standard makes no guarantees about its behavior. Compilers exploit this for optimization by assuming it will never happen.
For example, if you compile
#include <limits.h>
#include <stdio.h>
__attribute__((noinline,noclone)) //or skip the attr & define it in another tu
_Bool a_plus1_gt_b(int a, int b) { return a + 1 > b; }
int main()
{
printf("%dn", a_plus1_gt_b(INT_MAX,0)); //0
printf("%dn", INT_MAX+1); //1
}
on gcc with -O3
, it'll very likely print
1
-2147483648
answered Dec 22 '18 at 23:30
PSkocik
32.4k64770
32.4k64770
add a comment |
add a comment |
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%2f53899902%2fwhats-the-point-using-unsigned-int-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
Tip: By default, most C compilers are very reticent with providing unsolicited warnings. Ask it to speak up, and you will be astounded.
– Deduplicator
Dec 22 '18 at 22:57
5
"stored the value with no problem": there was a problem.
– DYZ
Dec 22 '18 at 22:58
Duplicate answer???: stackoverflow.com/questions/5169692/…
– Hayden
Dec 22 '18 at 22:59
1
Try this:
int main(){ unsigned int a = -1; if( 2U < a ){ printf("2 < '-1'n"); }}
– datenwolf
Dec 22 '18 at 23:04
1
If you present the code by which you purport to show that an unsigned integer stores a negative number, we will point out to you where it relies on undefined behavior, or else simply does not show what you claim.
– John Bollinger
Dec 22 '18 at 23:42