Integer promotion with the operator <<

Question

Similar to the question Bitshift and integer promotion?, I have a question about integer promotion when using left bitshifts.

unsigned int test(void)
{
  unsigned char value8;
  unsigned int result;

  value8 = 0x12;
  result = value8 << 8;
  return result;
}

In this case, will be the value8 first promote to unsiged int or is it implementation specific?

6.5.7 Bitwise shift operators ... 3 Sematics ...
The integer promotions are performed on each of the operands. The type of the result is that of the promoted left operand. If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined.

It says that the "The integer promotions are performed on each of the operands.", but what is here the promotion rule?

I assume that it should be convert to int if lesser rank than int, but I can't find it.

I ask this, as one compiler (Renesas nc30wa) doesn't promote to int, so the result is always 0 for my sample.

On this platform, a char is 8 bit wide and int 16 bits.

Answer 1

The phrase "the integer promotions" is a very specific thing, found in (for C99) section 6.3.1.1 Booleans, characters, and integers:

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. These are called the integer promotions. All other types are unchanged by the integer promotions.

So assuming your unsigned char can be held in an int, it will be promoted to an int. On those rare platforms where unsigned char is as wide as an int, it will promote to an unsigned int.

This is only changed slightly in C11:

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.

If a specific compiler doesn't follow this behaviour, then it's not really conforming. However, given that the compiler you listed is for embedded systems, it's not really surprising.

Many are built for specific purposes and conformance is not always high on the list of requirements. There may be compiler flags that will allow it to more closely conform to the standard.

---

Looking at your particular environment, the M16C Series,R8C Family C Compiler Package V.5.45 C Compiler has, in section 2.1.4 nc30 Command Line Options, subsection f. Generated code modification options:

-fextend_to_int, -fETI: Performs operation after extending char-type data to the int type. Extended according to ANSI standards.

although I suspect -fansi is probably a better choice since it covers a few other things as well.