2

From k&R C

  • First, if either operand is long double, the other is converted to long double.
  • Otherwise, if either operand is double, the other is converted to double.
  • Otherwise, if either operand is float, the other is converted to float.
  • Otherwise, the integral promotions are performed on both operands; ...

This would mean below expression

char a,b,c;

c=a+b;

is actually caculated as

c = char((int)a+(int)b);

What is the rationale behind this rule?

Do these conversions happen if a, b and c were short ?

Mat
  • 202,337
  • 40
  • 393
  • 406
Hari
  • 153
  • 8

3 Answers3

5

No that's not actually true. C99 Section 5.1.2.3 Program execution, clause 10 covers exactly the case you ask about:

EXAMPLE 2
In executing the fragment
char c1, c2;
c1 = c1 + c2;
the "integer promotions" require that the abstract machine promote the value of each variable to int size and then add the two ints and truncate the sum.

Provided the addition of two chars can be done without overflow, or with overflow wrapping silently to produce the correct result, the actual execution need only produce the same result, possibly omitting the promotions.

So, if the operation is known to produce the same result, there's no requirement for using the wider values.

But if you want the rationale behind a specific decision made in the standard, you have to look at, ..... wait for it, ..... yes, the Rationale document :-)

In section 6.3.1.8 of that rationale (sections match those in the standard), it states:

Explicit license was added to perform calculations in a “wider” type than absolutely necessary, since this can sometimes produce smaller and faster code, not to mention the correct answer more often.

Calculations can also be performed in a “narrower” type by the as if rule so long as the same end result is obtained.

paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
  • So as long as Implementation ensures 'char((int)a+(int)b)' and 'a+b' are same promotions can be omitted ? – Hari Jan 20 '12 at 07:06
  • 1
    It should be mentioned that the cited part of the standard covers program flow and possible optimizations. It is always best to assume that integer promotion takes place, or you might end up with bugs. Take for example `(c1+c2) / c3` where c1+c2 might overflow. The compiler can't optimize away the promotion there, as it would give a different result. – Lundin Jan 20 '12 at 07:48
2

Several instruction set architectures do not have any arithmetic machine instructions to operate on less-than-a-word integers (like short and char). So requiring that convention makes thing simpler for the compiler. And most of the time, converting to word and operating on word-sized operands is enough.

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
1

Do these conversions happen if a, b and c were short ?

Yes, integer promotions are done on all small integer types: char, short and C99 bool.

Strictly speaking, a C program cannot perform any form of arithmetic on anything smaller than an int, unless the compiler optimizes away the integer promotions.

Lundin
  • 195,001
  • 40
  • 254
  • 396
  • Out of curiosity: have you ever seen a compiler which (incorrectly) optimizes away the integer promotions? – pmor Apr 25 '22 at 20:56
  • @pmor Optimizing away - sure. Incorrectly, no. It may however optimize code taking implicit promotion in account, such as optimizing `uint8_t u8=0xAA; u8 = ~u8 >> 4;` into pure 8 bit instructions but still resulting in `0xF5`. An incorrect optimization would be to carry out the `~u8` with an 8 bit instruction giving the result `0x55` then shifting into end result `0x05`, but I haven't seen something like that. Go look at early versions of MPLAB for PIC maybe, it had a nasty reputation for being non-compliant. – Lundin Apr 26 '22 at 06:43