integer promotion in c

Question

Let say I have a 32-bit machine.

I know during integer promotion the expressions are converted to:

int if all values of the original type can be represented in int
unsigned otherwise

Could you please explain what will happen for the following expression? and In general, how ranking works here?

First snippet:

int16_t  x, pt;
int32_t  speed;
uint16_t length;
x = (speed*pt)/length;

Second one:

x = pt + length;

#EDIT:

I found the following link that has described the issue very clearly: Implicit type conversion.

Concretely, read the answer of Lundin, very helpful!

Question is impossible answer without knowing `sizeof(int)` relative to `sizeof(si16)` and others. — user694733, Jun 09 '17 at 10:20
"Let say i have 32 bit machine." is not at all relevant. We need to know the details of your `int`. — Bathsheba, Jun 09 '17 at 10:21
@ David Bowling , si16 means signed short (size 16 bit) , si32 bit means signed int (size 32 bit) and u16 means unsigned short (size 16) — Monir, Jun 09 '17 at 10:24
I hope the info on this page can help you: https://www.tutorialspoint.com/cprogramming/c_type_casting.htm — Jimmy, Jun 09 '17 at 10:31
Why are you using, e.g., `si32`? This is not at all clear. Is this a fixed-width type, as your comment suggests: `int32_t`, or is this an `int`, as your comment suggests? Same question for the other unspecified `typedef`s. — ad absurdum, Jun 09 '17 at 10:34
@Jimmy That's a bad tutorial, the author got the terms all wrong, mixing up casts and conversions. And he seems to be living in the year 1990, for example all his examples invoke undefined behavior since the OS might use the return value of main(). Don't recommend newbies to read such old crap please. — Lundin, Jun 09 '17 at 11:16

Lundin · Answer 1 · 2022-01-10T09:09:01.807

The integer promotion rule, correctly cited C11 6.3.1.1:

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.

Where "otherwise, it is converted to an unsigned int" is in practice only used in one particular special case, namely where the smaller integer type unsigned short has the same size as unsigned int. In that case it will remain unsigned.

Apart from that special case, all small integer types will always get promoted to (signed) int regardless of their signedness.

Assuming 32 bit int, then:

 x = (speed*pt)/length;

speed is signed 32, it will not get promoted. pt will get integer promoted to int (signed 32). The result of speed*pt will have type int.

length will get integer promoted to int. The division will get carried out with operands of type int and the resulting type will be int.

The result will get converted to signed 16 as it is assigned to x (lvalue conversion during assignment).

x = pt + length; is similar, here both operands of + will get promoted to int before addition and the result will afterwards get converted to signed 16.

For details see Implicit type promotion rules.

could you please explain the line : "All other types are unchanged by the integer promotions." — Monir, Jun 09 '17 at 11:41
@Monir With some more context, it means that all types that aren't of the "small integer types" aren't affected by the rule. The small integer types are: bool, char, short (and their stdint.h equivalents). — Lundin, Jun 09 '17 at 11:46
It is allowed to apply an operator without converting it first to int provided you can prove it will not overflow. — alinsoar, Jun 09 '17 at 12:14
@alinsoar Compilers may optimize such expressions but they are indeed not allowed to optimize out side effects caused by promotion, including implicit change of signedness. — Lundin, Jun 09 '17 at 12:37

score 2 · Answer 2 · edited Jan 10 '22 at 09:04

2

The integer promotion rules are defined in 6.3.1.8 Usual arithmetic conversions.

1.  int16_t  x, pt;
    int32_t  speed;
    uint16_t length;
    x = (speed*pt)/length;

2. x =  pt + length;

Ranking means effectively the number of bits from the type as defined by CAM in limits.h. The standards imposes for the types of lower rank in CAM to correspond types of lower rank in implementation.

For your code,

speed * pt

is multiplication between int32_t and int16_t, which means, it is transformed in

speed * (int16_t => int32_t) pt

and the result tmp1 will be int32_t.

Next, it will continue

tmp1_int32 / length

Length will be converted from uint16_t to int32_t, so it will compute tmp2 so:

tmp1_int32 / (uint16_t => int32_t) length

and the result tmp2 will be of type int32_t.

Next it will evaluate an assignment expression, left side of 16 bits and the right side of 32, so it will cut the result so:

x = (int32_t => int16_t) tmp2_int32

Your second case will be evaluated as

x = (int32_t => int16_t) ( (int16_t => int32_t) pt + (uint16_t => int32_t) length )

In case an operator has both operands with rank smaller than the rank of int, the CAM allows to add both types if the operation does not overflow and then to convert the result to integer.

In other words, it is possible to covert INT16+INT16 either in

 INT16+INT16

or in

 (int32_t => int16_t) ((int16_t => int32_t) INT16 + (int16_t => int32_t) INT16)

provided the addition can be done without overflow.

edited Jan 10 '22 at 09:04

einpoklum

118,144
57
340
684

answered Jun 09 '17 at 11:56

alinsoar

15,386
4
57
74

1

"Ranking", that is _conversion rank_, is formally specified in 6.3.1.1. – Lundin Jun 09 '17 at 12:38
1

What is "CAM" supposed to mean? – Lundin Jun 09 '17 at 12:40
c abstract machine – alinsoar Jun 09 '17 at 12:59
I was talking about integer promotions concerning my reference, not about ranking. – alinsoar Jun 09 '17 at 12:59
to be more precise, CAM means the abstract semantics defined by the standard. – alinsoar Jun 09 '17 at 13:00
I don't see what the abstract machine has to do with limits.h. And please do not invent more three-letter abbreviations... "CAM" is neither a formal nor a de facto standard term. – Lundin Jun 09 '17 at 13:35
Regarding optimizations, the compiler is actually not always allowed to do optimizations like described, not only because of overflows, but also because integer promotion might cause implicit change of signedness and other such nasty things that may not get optimized away, or the meaning of the program would be changed. – Lundin Jun 09 '17 at 13:37
For example `unsigned char a = 1; unsigned char b = 2; if(a - b < 0) puts("< 0");` must result in "< 0" getting printed even though there are no overflows present. The compiler is not allowed to skip the unintended side effect caused by the promotion - it is not allowed to evaluate the expression as unsigned char type which would have given the result 255. – Lundin Jun 09 '17 at 13:41
@Lundin I am sorry to tell you that you are wrong. Look more over the C standard. – alinsoar Jun 09 '17 at 13:43
In limits.h are defined the minimum number of bits for each type and this is in direct correlation with the rank of each type (apart from int, that is a special case) – alinsoar Jun 09 '17 at 13:45
All the C standard says in terms of the abstract machine is that the compiler is allowed to optimize code if it can deduct that result will be the same as when no optimizations were present. See the above code example - optimizations are required to give a negative value, even if the actual calculation of `a - b` is carried out on a 8 bit type. For the same reason as `sizeof(a - b)` must give result 4 on a 32 bit machine. – Lundin Jun 09 '17 at 13:50
As already mentioned, rank is specified by 6.3.1.1 and not by limits.h or anything else: `The rank of long long int shall be greater than the rank of long int, which shall be greater than the rank of int, which shall be greater than the rank of short int, which shall be greater than the rank of signed char.` – Lundin Jun 09 '17 at 13:51
I know where the rank is. I said that it is in correlation with limits.h. This is my observation and you can check it. – alinsoar Jun 09 '17 at 13:52
In limits.h, 5.2.4.2.1, SHRT_MIN and SHRT_MAX have the very same value as INT_MIN and INT_MAX. Yet `int` always have greater conversion rank than `short`. – Lundin Jun 09 '17 at 13:54
Did you read what I said above ? ``In limits.h are defined the minimum number of bits for each type and this is in direct correlation with the rank of each type (apart from int, that is a special case)`` – alinsoar Jun 09 '17 at 13:55
Perhaps you could quote the standard where exactly "the minimum number of bits" are specified then? Since `CHAR_BITS` is the only such constant specified by the standard. – Lundin Jun 09 '17 at 14:06
It provides minimum limits and it specifies that it's used the base 2 (one of 3 possible encodings in base 2 are allowed) so one can deduce. – alinsoar Jun 09 '17 at 14:14
@Lundin Some compilers for embedded system might have an option to compile more optimal code if user wants to do so. Also, it is not a good idea to have code that rely on integer promotion... as it somehow hide the intent. – Phil1970 Jun 09 '17 at 16:25
@Phil1970 Yes absolutely, but they are not allowed to optimize any side effects caused by implicit promotion, such as change of signedness, since those side effects could be intentional. Indeed it is a horrible idea to write code that relies on implicit promotion, but the compiler can't tell if such reliance is intentional or accidental. – Lundin Jun 12 '17 at 06:32

integer promotion in c

2 Answers2

Linked

Related