integer-promotion | 易学教程

Does Unary + operator do type conversions?

阅读更多关于 Does Unary + operator do type conversions?

问题 Till now I was believing that there is no use of unary + operator. But then I came across with following example: char ch; short sh; int i; printf("%d %d %d",sizeof(ch),sizeof(sh),sizeof(i)); // output: 1 2 4 printf("%d %d %d",sizeof(+ch),sizeof(+sh),sizeof(i)); // output: 4 4 4 Does it mean + is doing type conversion here? Because it is behaving same as following printf("%d %d %d",sizeof((int)ch),sizeof((int)sh),sizeof(i)); // output: 4 4 4 This forces me to think + is doing type conversion.

Should bit-fields less than int in size be the subject of integral promotion?

阅读更多关于 Should bit-fields less than int in size be the subject of integral promotion?

问题 Let's say I have following struct : struct A { unsigned int a : 1; unsigned int b : 1; }; What interests me is the type of expression a + b . While technically bit-fields have "type" with size less than int so integral promotion probably should happen and then result is int like it happens to be in gcc and clang. But since it's impossible to extract the exact type of bit-field itself and it will always be deduced to be its "big" type (i.e. unsigned int in this case) is it correct that

How possibly can a unary +/- operator cause integral promotion in “-a” or “+a”, 'a' being an arithmetic data type constant/variable?

阅读更多关于 How possibly can a unary +/- operator cause integral promotion in “-a” or “+a”, 'a' being an arithmetic data type constant/variable?

问题 This seemingly trivial line is taken from the C book my Mike Banahan & Brady (Section 2.8.8.2). I can understand how implicit promotion comes into play in expressions like c=a+b depending on the types of the operands, but I am unable to grasp how and in which case the same can figure in something like -b , where b is any legitimate operand. Can you explain it and then give a proper example? Extracted text follows: The usual arithmetic conversions are applied to both of the operands of the

Bitwise negation of unsigned char

阅读更多关于 Bitwise negation of unsigned char

问题 This is a question relating the c99 standard and concerns integer promotions and bitwise negations of unsigned char. In section 6.5.3.3 it states that: The integer promotions are performed on the operand, and the result has the promoted type. If the promoted type is an unsigned type, the expression ~E is equivalent to the maximum value representable in that type minus E. Am I understanding that correctly when I say that, that means that: unsigned int ui = ~ (unsigned char) ~0; // ui is now

Is `uint_fast32_t` guaranteed to be at least as wide as `int`?

阅读更多关于 Is `uint_fast32_t` guaranteed to be at least as wide as `int`?

问题 The C standard specifies that integer operands smaller than int will be promoted to int before any arithmetic operations are performed upon them. As a consequence, operations upon two unsigned values which are smaller than int will be performed with signed rather than unsigned math. In cases where it is important to ensure that operation on 32-bit operands will be performed using unsigned math (e.g. multiplying two numbers whose product could exceed 2⁶³) will use of the type uint_fast32_t be

What is (INT32_MIN + 1) when int32_t is an extended integer type and int is 32-bit one's complement standard integer type

阅读更多关于 What is (INT32_MIN + 1) when int32_t is an extended integer type and int is 32-bit one's complement standard integer type

问题 Imagine this situation. int32_t is an extended integer type and it's represented in two's complement (as the standard required int32_t to be represented). This means that INT32_MIN is -2147483648 ( 0x80000000 ). Meanwhile int is a standard integer type and it's represented in one's complement (as the standard allows). This means that INT_MIN is -2147483647 . Now correct me if I'm wrong, but I think both types have the same width , which means, according to 6.3.1.1.1 (emphasis mine): The rank

Operator precedence and automatic promotion (to avoid overflow)

阅读更多关于 Operator precedence and automatic promotion (to avoid overflow)

Finding the size of some data in bytes is a common operation. Contrived example: char *buffer_size(int x, int y, int chan_count, int chan_size) { size_t buf_size = x * y * chan_count * chan_size; /* <-- this may overflow! */ char *buf = malloc(buf_size); return buf; } The obvious error here is the ints will overflow (an 23171x23171 RGBA byte buffer for eg). What are the rules for promotion when multiplying 3 or more values? (Multiplying a pair of values is simple) We could play it safe and just cast: size_t buf_size = (size_t)x * (size_t)y * (size_t)chan_count * (size_t)chan_size; Another

Why isn't common_type<long, unsigned long>::type = long long?

阅读更多关于 Why isn't common_type::type = long long?

问题 common_type<long, unsigned long>::type is unsigned long because concerning the operands after integral promotion the standard says... [...] if the operand that has unsigned integer type has rank greater than or equal to the rank of the type of the other operand, the operand with signed integer type shall be converted to the type of the operand with unsigned integer type Not to call the integral promotion system buggy, but it seems like if there is a bigger signed integer type which can can

What's the difference between integer promotions and integer conversions in C++

阅读更多关于 What's the difference between integer promotions and integer conversions in C++

Section 4.5 of the C++ standard (integer promotion) talks about specific cases of converting integral types to types with a higher rank. Section 4.7 of the C++ standard (integral conversions) begins with (bullet 4.7.1): An rvalue of an integer type can be converted to an rvalue of another integer type. An rvalue of an enumeration type can be converted to an rvalue of an integer type. As far as I understand conversions described in 4.5 (maybe except for the bullet 4.5.3 (enums)) can be performed by using the techniques from 4.7 section alone: 4.5.1 and 4.5.2 are completely covered by 4.7.1; 4.5

Would making plain int 64-bit break a lot of reasonable code?

阅读更多关于 Would making plain int 64-bit break a lot of reasonable code?

Until recently, I'd considered the decision by most systems implementors/vendors to keep plain int 32-bit even on 64-bit machines a sort of expedient wart. With modern C99 fixed-size types ( int32_t and uint32_t , etc.) the need for there to be a standard integer type of each size 8, 16, 32, and 64 mostly disappears, and it seems like int could just as well be made 64-bit. However, the biggest real consequence of the size of plain int in C comes from the fact that C essentially does not have arithmetic on smaller-than- int types. In particular, if int is larger than 32-bit, the result of any