I'm doing the following comparison:
uint32_t value = 1000;
if(value < 100)
{
// do something
}
What get's casted to what in this case? Does 'value' get casted to an integer? Does 100 get casted to an integer or unsigned integer?
First, all numeric constant have a type. In the case of the constant 100, because it is decimal, has no suffix, and can fit in the range of an int, the constant has type int.
How the comparison is performed is dictated by the usual arithmetic conversions. Specifically, the conversion rules for integer types are specified in section 6.3.1.8p1 of the C standard as follows:
... the integer promotions are performed on both operands.
Then the following rules are applied to the promoted operands:
If both operands have the same type, then no further conversion is needed.
Otherwise, if both operands have signed integer types or both have unsigned integer types, the operand with the type of lesser
integer conversion rank is converted to the type of the operand
with greater rank.
Otherwise, if the operand that has unsigned integer type has rank greater or equal to the rank of the type of the
other operand, then the operand with signed integer type is
converted to the type of the operand with unsigned integer
type.
Otherwise, if the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned
integer type, then the operand with unsigned integer type is
converted to the type of the operand with signed integer type.
Otherwise, both operands are converted to the unsigned integer type corresponding to the type of the operand with signed
integer type
Assuming an int on your platform is 32 bits, that makes uint32_t the same as an unsigned int, so you're using a signed type and an unsigned type of the same size in an expression. That being the case, the third bullet point above applies, namely the value 100 (which has type int) is converted to an unsigned int and then the values are compared.
In this case, the value 100 is also within the range of an unsigned int, so there is no conversion of the actual value. If it was instead something like -100, that value is not in the range of an unsigned int, which means the value would be converted to be within that range. Again, assuming a 32 bit int the value would be 232 - 100.
If two integer expressions have the same rank as in your example provided that the type uint32_t is an alias for the type unsigned int then the signed type is converted to the unsigned type. That is the integer literal 100 that has the type signed int is converted to the type unsigned int.
From the C Standard (6.3.1.1 Boolean, characters, and integers)
— The rank of any unsigned integer type shall equal the rank of the
corresponding signed integer type, if any.
And (6.3.1.8 Usual arithmetic conversions)
Otherwise, if the operand that has unsigned integer type has rank
greater or equal to the rank of the type of the other operand, then
the operand with signed integer type is converted to the type of the
operand with unsigned integer type
Related
... the integer promotions are performed on both operands.
Then the following rules are applied to the promoted operands:
If both operands have the same type, then no further conversion is needed.
Otherwise, if both operands have signed integer types or both have unsigned integer types, the operand with the type of lesser integer conversion rank is converted to the type of the operand with greater rank.
Otherwise, if the operand that has unsigned integer type has rank greater or equal to the rank of the type of the other operand, then the operand with signed integer type is converted to the type of the operand with unsigned integer type.
Otherwise, if the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned integer type, then the operand with unsigned integer type is converted to the type of the operand with signed integer type.
Otherwise, both operands are converted to the unsigned integer type corresponding to the type of the operand with signed integer type
Can someone explain me the difference between the last and penultimate points from above? Why is the last one needed? Aren't all the cases covered by the first 4? If someone can give an example would be perfect. Thanks
Otherwise, both operands are converted to the unsigned integer type
corresponding to the type of the operand with signed integer type
Let's consider a system where sizeof( long ) is equal to sizeof( unsigned int ) (for example the both are equal to 4).
In this case though the rank of the type long is greater than the rank pf the type unsigned int nevertheless an operand of the signed type long is unable to represent all values of the type unsigned int.
In this case the both operands used in a binary operation are converted to the type unsigned long.
Or another example when in some systems sizeof( long long ) is equal to sizeof( unsigned long ) and equal to 8. In this case again the both operands of these types will be converted to the type unsigned long long because the rank of long long is greater than the rank of the type unsigned long but not all values of operand of the type unsigned long can be represented by an object of the signed type long long.
That is this quote describes the situation when the rank pf an operand of a signed integer type is greater than the rank of an unsigned integer type but the operand of the signed integer type is unable to represent all values of the operand of the unsigned integer type.
The preceding quote
Otherwise, if the type of the operand with signed integer type can
represent all of the values of the type of the operand with unsigned
integer type, then the operand with unsigned integer type is converted
to the type of the operand with signed integer type.
describes the situation when the rank of a signed integer type is greater than the rank of an unsigned integer type and operand of the signed integer type can represent all values of operand of the unsigned integer type. For example when one operand of the type long and other of the type unsigned int and sizeof( long ) is equal to 8 and sizeof( unsigned int ) is equal tp 4.
We reach (4) when one has a signed type and one has an unsigned type, and the signed type has a greater rank.
For example, this could be a long and a unsigned int.
What differentiates whether (4) or (5) is used is whether the signed type can represent all of the values of the unsigned type.
On a system with a 32 bit long and a 16 bit unsigned int, we'd use case 4
We'd use long.
On a system with a 32 bit long and a 32 bit unsigned int, we'd use case 5 because 4,294,967,295 can be represented by this unsigned int, but can't be represented by this long.
We'd use unsigned long.
When adding signed and unsigned values we follow these two rules (from https://stackoverflow.com/a/2280810/1073672)
Otherwise, if the operand that has unsigned integer type has rank greater or equal to the rank of the type of the other operand, then the operand with signed integer type is converted to the type of the operand with unsigned integer type.
Otherwise, if the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned integer type, then the operand with unsigned integer type is converted to the type of the operand with signed integer type.
Which of the above rules will be triggered for:
unsigned int ui = 4;
ui = ui + 532;
The type of the constant 532 is int, which is signed.
Looking at the first rule, since unsigned int and int have the same rank, then the unsigned type's rank is greater than or equal to the signed type's. The first rule matches. The signed 532 is converted to unsigned int before the addition.
Even if the first rule hadn't matched, the addition cannot match the second rule, because a signed int cannot represent all the values of an unsigned int. (There are the same number of possible signed ints as unsigned ints, but for example, -1 is a signed int but not an unsigned int, therefore there must be at least one unsigned int that cannot be represented as a signed int.)
For example, If I have,
int a = 42;
unsigned b = 10;
int c = a + b;
For this statement, int c = a + b; Would a be first converted to an unsigned int or would it be b that will be converted to a signed int? Both unsigned int and signed have the same conversion rank so how do we know which one will be converted? Is there a Standard rule?
Short answer: Per C99 6.3.1.8-p1, as value will be converted to an unsigned int by, per C99 6.3.1.3-p2, having UINT_MAX+1 added to it until it falls in the range allowed by unsigned int. Since it is already in that range, no addition will be performed. By C99 6.3.1.3-p3, the results assigned back to int c would be implementation defined if (p1) and (p2) didn't apply. But in this case note the "value" clause of 6.3.1.3-p1. The value (52) in this case can be represented by int, so it is not changed, and is defined.
C99 6.3.1.3 Signed and unsigned integers
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.
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.60)
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.
C99 6.3.1.8 Usual arithmetic conversions
Many operators that expect operands of arithmetic type cause conversions and yield result types in a similar way. The purpose is to determine a common real type for the operands and result. For the specified operands, each operand is converted, without change of type domain, to a type whose corresponding real type is the common real type. Unless explicitly stated otherwise, the common real type is also the corresponding real type of the result, whose type domain is the type domain of the operands if they are the same, and complex otherwise. This pattern is called the usual arithmetic conversions:
First, if the corresponding real type of either operand is long double, the other operand is converted, without change of type domain, to a type whose corresponding real type is long double.
Otherwise, if the corresponding real type of either operand is double, the other operand is converted, without change of type domain, to a type whose corresponding real type is double.
Otherwise, if the corresponding real type of either operand is float, the other operand is converted, without change of type domain, to a type whose corresponding real type is float.62)
Otherwise, the integer promotions are performed on both operands. Then the following rules are applied to the promoted operands:
If both operands have the same type, then no further conversion is needed.
Otherwise, if both operands have signed integer types or both have unsigned integer types, the operand with the type of lesser integer conversion rank is converted to the type of the operand with greater rank.
Otherwise, if the operand that has unsigned integer type has rank greater or equal to the rank of the type of the other operand, then the operand with signed integer type is converted to the type of the operand with unsigned integer type.
Otherwise, if the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned integer type, then the operand with unsigned integer type is converted to the type of the operand with signed integer type.
Otherwise, both operands are converted to the unsigned integer type corresponding to the type of the operand with signed integer type.
6.3.1.8p1: Otherwise, the integer promotions are
performed on both operands. Then the following rules are applied to the promoted operands: If both operands have the same
type, then no further conversion is needed. Otherwise, if both operands have signed integer types or both have unsigned integer
types, the operand with the type of lesser integer conversion rank is converted to the type of the operand with greater rank.
Otherwise, if the operand that has unsigned integer type has rank greater or equal to the rank of the type of the other operand,
then the operand with signed integer type is converted to the type of the operand with unsigned integer type. Otherwise,
if the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned
integer type, then the operand with unsigned integer type is converted to the type of the operand with signed integer type.
Otherwise, both operands are converted to the unsigned integer type corresponding to the type of the operand with signed
integer type.
For the bolded rule to be applied it would seem to imply you need to have have an unsigned integer type who's rank is less than the signed integer type and the signed integer type cannot hold all the values of the unsigned integer type.
Is there a real world example of such a case or is this statement serving as a catch-all to cover all possible permutations?
If you had a platform where sizeof(long int)==sizeof(int), then signed long int and unsigned int would fall into this rule. In any case, the standard does not dictate that conversion rank is equivalent to size, only that conversion rank provides an ordering that is a valid ordering on size (6.3.1.1.p1.1 (sp?)):
No two signed integer types shall have the same rank, even if they have the same
representation.
I have a query about data type promotion rules in C language standard.
The C99 says that:
C integer promotions also require that "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."
My questions is in case of a C language expression where unsigned int and signed int are present, which type will be promoted to what type?
E.g. int cannot represent all the values of the unsigned int (values larger than MAX_INT values) whereas unsigned int cannot represent the -ve values, so what type is promoted to what in such cases?
I think you are confusing two things. Promotion is the process by which values of integer type "smaller" that int/unsigned int are converted either to int or unsigned int. The rules are expressed somewhat strangely (mostly for the benefit of handling adequately char) but ensure that value and sign are conserved.
Then there is the different concept of usual arithmetic conversion by which operands of arithmetic operators are converted to a common type. It begins by promoting the operand (to either int or unsigned) if they are of a type smaller than int and then choosing a target type by the following process (for integer types, 6.3.1.8/1)
If both operands have the same type, then no further conversion is needed.
Otherwise, if both operands have signed integer types or both have unsigned
integer types, the operand with the type of lesser integer conversion rank is
converted to the type of the operand with greater rank.
Otherwise, if the operand that has unsigned integer type has rank greater or
equal to the rank of the type of the other operand, then the operand with
signed integer type is converted to the type of the operand with unsigned
integer type.
Otherwise, if the type of the operand with signed integer type can represent
all of the values of the type of the operand with unsigned integer type, then
the operand with unsigned integer type is converted to the type of the
operand with signed integer type.
Otherwise, both operands are converted to the unsigned integer type
corresponding to the type of the operand with signed integer type.
(Note that ISTR that those rules have changed slightly between C89 and C99)
I think the following answers your question:
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.