I'm new to C and have seen code such as (unsigned)b
Does that imply that b will be an unsigned int? Or what type does it imply?
b will be whatever type it was to begin with. That doesn't change
(unsigned)b will evaluate as whatever value b is, but that is subject to the cast to unsigned, which is synonymous with unsigned int.
How that happens depends entirely on the type of b to begin with, whether that type is convertible to unsigned int, and whether the value contained therein falls unscathed between 0...UINT_MAX or not.
Ex:
#include <stdio.h>
void foo(unsigned int x)
{
printf("%u\n", x);
}
int main()
{
int b = 100;
foo((unsigned)b); // will print 100
char c = 'a';
foo((unsigned)c); // will print 97 (assuming ASCII)
short s = -10; // will print 4294967286 for 32-bit int types
// (see below for why)
foo((unsigned)s);
// won't compile, not convertible
//struct X { int val; } x;
//foo((unsigned)x);
}
The only part of this that may raise your eye brow is the third example. When a value of a convertible type to an unsigned type is out of the unsigned type's range (ex: negative values are not same-value representable with any unsigned target types), the value is converted by repeatedly added the maximum value representable by the unsigned target plus-one to the out-of-range value until such time as it falls within the valid range of the unsigned type.
In other words, because -10 is not within the valid representation of unsigned int, UINT_MAX+1 is added to -10 repeatedly (only takes once in this case) until the result is within 0...UINT_MAX.
Hope that helps.
unsigned is a short of unsigned int
signed is a short of signed int
long is the short of long int
long long is the short of long long int
short is the short of short int
Related
I have a doubt from the below 2 code snippets.
I ran this code on 64-bit machine (x86_64-linux-gnu). I can see the value Val overflows when the data type is unsigned integer.
#include<stdio.h>
main()
{
unsigned int Val = 0xFFFFFFFF-15, Val2 = 0xFFFFFFFF;
if (Val+16 < Val2)
{
printf("Val is less than Val2\n");
}
}
If the data type is unsigned char it does not overflow.
#include<stdio.h>
main()
{
unsigned char Val = 0xFF-15, Val2 = 0xFF;
if (Val+16 < Val2)
{
printf("Val is less than Val2\n");
}
}
I have two questions:
Does the value Val get promoted to high data type when the data type is unsigned char?
If yes, why did not it get promoted from 32-bit to 64-bit unsigned long?
The C11 standard says the following (C11 6.3.11p2.2):
If an int can represent all values of the original type (as restricted by the width, for a bit-field), the value is converted to an int; otherwise, it is converted to an unsigned int. These are called the integer promotions. All other types are unchanged by the integer promotions.
Thus:
unsigned char will be promoted - however it is an implementation detail whether int can represent all values of unsigned char - so it might be promoted to an unsigned int on those platforms. Yours is not one of those platforms, thus your second comparison is (int)Val + 16 < (int)Val2.
as the last sentence of the quoted paragraph tells, an unsigned int is never promoted. Since the arithmetic is done on unsigned ints in the first fragment, the result of 0xFFFFFFFF - 15 + 16 is 0U on a computer with 32-value-bit unsigned int.
Yes, in the second case the numbers are promoted to int. If you modify your code thus:
#include<stdio.h>
int main()
{
unsigned char Val = 0xFF-15, Val2 = 0xFF;
if ((unsigned char)(Val+16) < Val2)
{
printf("Val is less than Val2\n");
}
}
You will get the behaviour you expect.
What is the difference between
long int numberOfPoints = 131071100; and
long int numberOfPoints = 131071100L;
and is an assignment such as
int numberOfPoints = 131071100L;
legal? And if it is what is the difference between that and the previous two?
The type of an unsuffixed integer constant like 131071100 is the first of int, long int, and long long int in which its value can be represented. The value of 131071100 is always mathematically correct; only its type varies (and since long int is at least 32 bits, it's always either an int or a long int).
With the L suffix, it's of type long int or long long int; again, the value is always correct -- and it happens that 131071100L is always of type long int.
It's perfectly valid to initialize an object of some arithmetic type with an expression of a different numeric type. The value is implicitly converted to the target type. And in this case, since the target type is long int, there is no risk of overflow.
For your particular case, the only difference between
long int numberOfPoints = 131071100;
and
long int numberOfPoints = 131071100L;
is that the latter is slightly more explicit; the meaning is exactly the same.
The L suffix is still needed if the expression is more complicated than a single constant. For example, if you write:
long int foo = 1024 * 1024 * 1024;
then each constant 1024 is of type int -- and so is the entire expression. If int happens to be just 16 bits, then the multiplication will overflow, even though the mathematical result would fit in a long int. (The type of a literal is adjusted depending on its value; the type of a large expression is not.) To avoid that problem, you can write:
long int foo = 1024L * 1024L * 1024L;
(A previous answer here was incorrect and has been amended.)
Per the ANSI C specification (similar language exists in C99 and C++ specifications):
The type of an integer constant is the first of the corresponding list
in which its value can be represented.
Unsuffixed decimal: int, long
int, unsigned long int.
Unsuffixed octal or hexadecimal: int, unsigned
int, long int, unsigned long int.
Suffixed by the letter u or U: unsigned int, unsigned long int.
Suffixed by the letter l or L: long
int, unsigned long int.
Suffixed by both the letters u or U and l or L: unsigned long int.
Therefore, there will not be any difference between the two expressions, since C guarantees that the constant's type will be long enough to hold the value.
Suppose the following:
unsigned char foo = 3;
unsigned char bar = 5;
unsigned int shmoo = foo + bar;
Are foo and bar values guaranteed to be promoted to int values for the evaluation of the expression foo + bar -- or are implementations allowed to promote them to unsigned int?
In section 6.2.5 paragraph 8:
For any two integer types with the same signedness and different integer conversion rank
(see 6.3.1.1), the range of values of the type with smaller integer conversion rank is a
subrange of the values of the other type.
In section 6.2.5 paragraph 9:
If an int can represent all values of the original type, the value is converted to an int; otherwise, it is converted to an unsigned int.
The guarantee that an integer type with smaller integer conversion rank has a range of values that is a subrange of the values of the other type seems dependent on the signedness of the integer type.
signed char corresponds to signed int
unsigned char corresponds to unsigned int
Does this mean that the value of an unsigned char is only guaranteed to be in the subrange of unsigned int and not necessarily int? If so, does that imply that an implementation could theoretically have an unsigned char value which is not in the subrange of an int?
are implementations allowed to promote them to unsigned int?
Implementations will promote to unsigned int if not all unsigned char values are representable in an int (as ruled by 6.2.5p9 in C99). See below for implementation examples.
If so, does that imply that an implementation could theoretically have an unsigned char value which is not in the subrange of an int?
Yes, example: DSP cpu with CHAR_BIT 16 or 32.
For example, TI C compiler for TMS320C55x: CHAR_BIT is 16 and UCHAR_MAX 65535, UINT_MAX 65535 but INT_MAX 32767.
http://focus.ti.com/lit/ug/spru281f/spru281f.pdf
I ran across this yesterday - hope that my answer is on topic.
uint8_t x = 10;
uint8_t y = 250;
if (x - y > 0) {
// never happens
}
if (x - y < 0U) {
// always happens
}
To my eyes at least it was appearing as though values x and y were being unexpectedly promoted, when in fact is was their result that was promoted.
When I multiply two unsigned chars in C like this:
unsigned char a = 200;
unsigned char b = 200;
unsigned char c = a * b;
Then I know I will have an overflow, and I get (40'000 modulo 256) as a result. When I do this:
unsigned char a = 200;
unsigned char b = 200;
unsigned int c = (int)a * (int)b;
I will get the correct result 40'000. However, I do not know what happens with this:
unsigned char a = 200;
unsigned char b = 200;
unsigned int c = a * b;
Can I be sure the right thing happens? Is this compiler dependent? Similarly, I don't know what happens when doing a subtraction:
unsigned char a = 1;
unsigned char b = 2;
int c = a - b;
When making "c" an unsigned char, I will probably get 255 as a result. What happens when I use an int like this?
Argument of arithmetic operators get the "usual arithmetic promotions".
In cases where int can represent all the values of all the operands (at it is the case for your example in most implementations), arguments are first converted to int. So in both cases, you get the correct result.
Copied from this answer In a C expression where unsigned int and signed int are present, which type will be promoted to what type?
6.3.1.3 Signed and unsigned integers
1 When a value with integer type is converted to another integer type other than _Bool, if the value can be represented by the new type, it is unchanged.
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.
3 Otherwise, the new type is signed and the value cannot be represented in it; either the >result is implementation-defined or an implementation-defined signal is raised.
Does C treat hexadecimal constants (e.g. 0x23FE) and signed or unsigned int?
The number itself is always interpreted as a non-negative number. Hexadecimal constants don't have a sign or any inherent way to express a negative number. The type of the constant is the first one of these which can represent their value:
int
unsigned int
long int
unsigned long int
long long int
unsigned long long int
It treats them as int literals(basically, as signed int!). To write an unsigned literal just add u at the end:
0x23FEu
According to cppreference, the type of the hexadecimal literal is the first type in the following list in which the value can fit.
int
unsigned int
long int
unsigned long int
long long int(since C99)
unsigned long long int(since C99)
So it depends on how big your number is. If your number is smaller than INT_MAX, then it is of type int. If your number is greater than INT_MAX but smaller than UINT_MAX, it is of type unsigned int, and so forth.
Since 0x23FE is smaller than INT_MAX(which is 0x7FFF or greater), it is of type int.
If you want it to be unsigned, add a u at the end of the number: 0x23FEu.