char and the usual arithmetic conversion rules

Question

I know this question has been asked and seemingly answered a gazillion times over but I can't seem to match the answers to my own experience.

The C standard specifies that for addition "both operands shall have arithmetic type" (6.5.6.1). Arithemitc types covers integer and floating types (6.2.5.18) and finally integer types are char, short, int, long and long long which exist as signed and unsigned types (6.2.5.4 and 6.2.5.6). According to the rules for usual arithmetic conversion "If both operands have the same type, then no further conversion is needed." So far so good.

It has been my understanding, as exemplified here from "The C Book", that "[n]o arithmetic is done by C at a precision shorter than int" which is where integral promotion is applied. I can find no reference to this in the standard by I seem to have seen this numerous times.

Since unsigned char is an arithmetic type and the rules for usual arithmetic conversion states that operands of the same type does not need conversion, why the need for integral promotion?

I tested this using two different compilers. I wrote a simple program which does char addition:

unsigned char a = 1;
unsigned char b = 2;
unsigned char c = a + b;

The target platform is an Atmel Mega8 uC using an 8 bit architecture. An integer addition would therefore require use of two registers if the operands should be subject to integral promotion.

Compiling this using imagecraft avr compiler with no optimization and with strict and ANSI C portability options enabled yields this assembly code:

mov R16, R20
add R16, R18

Using avr-gcc (I am not aware of an ANSI switch similar to gcc's -strict):

$ avr-gcc -O0 -mmcu=atmega8 -S -c main.c

The resulting assembly:

ldd r25,Y+1
ldd r24,Y+2
add r24,r25
std Y+3,r24

The resulting code in both cases operates on a single byte. I get similar results for bitwise | and & and logical || and &&. Does this mean then that standard allows arithmetic operations on charecter types without integral promotion or does it simply mean that these compilers are not standard complient?

---

Additional:

Turns out it all depends on the type the result is stored in. The example shown above is only true when the result is stored in a char, and it does not depend on the result of the addition. Setting a to 0xFF and b to 1 produces the exact same assembly code.

If the type of c is changed to unsigned int the resulting assembly looks like this:

mov R2,R20
clr R3
mov R16,R18 
clr R17
add R16,R2 
adc R17,R3 

Even in the case where the result can be held in a single byte, i.e. a=1 and b=2.

Answer 1

C 2011 (n1570) 6.3.1.8 (“Usual arithmetic conversions”) 1 states that the integer promotions are performed before considering whether the types are the same:

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…

Thus, in the C abstract machine, unsigned char values must be promoted to int before arithmetic is performed. (There is an exception for perverse machines where unsigned char and int have the same size. In this case, unsigned char values are promoted to unsigned int rather than int. This is esoteric and need not be considered in normal situations.)

In the actual machine, operations must be performed in a way that gets the same results as if they were performed in the abstract machine. Because only the results matter, the actual intermediate operations do not need to exactly match the abstract machine.

When the sum of two unsigned char values is assigned to an unsigned char object, the sum is converted to a unsigned char. This conversion essentially discards bits beyond the bits that fit in an unsigned char.

This means that the C implementation gets the same result whether it does this:

• Convert values to int.
• Add values with int arithmetic.
• Convert result to unsigned char.

or this:

• Add values with unsigned char arithmetic.

Because the result is the same, the C implementation may use either method.

For comparison, we can consider this statement instead: int c = a + b;. Also, suppose the compiler does not know the values of a and b. In this case, using unsigned char arithmetic to do the addition could yield a different result than converting the values to int and using int arithmetic. E.g., if a is 250 and b is 200, then their sum as unsigned char values is 194 (250 + 200 % 256), but their sum in int arithmetic is 450. Because there is a difference, the C implementation must use instructions that get the correct sum, 450.

(If the compiler did know the values of a and b or could otherwise prove that the sum fit in an unsigned char, then the compiler could again use unsigned char arithmetic.)

Answer 2

Here's the relevant part from C99:

6.3.1 Arithmetic operands
6.3.1.1 Boolean, characters, and integers
1 Every integer type has an integer conversion rank defined as follows:
...
2 The following may be used in an expression wherever an int or unsigned int may be used:
— An object or expression with an integer type whose integer conversion rank is less than the rank of int and unsigned int.
— A bit-field of type _Bool, int, signed int, or unsigned int.
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.

I agree it's obscure, but this is the closest you can find w.r.t. conversion of the various kinds of char or short or _Bool to int or unsigned int.

From the same source:

5.1.2.3 Program execution
In the abstract machine, all expressions are evaluated as specified by the semantics. An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced (including any caused by calling a function or accessing a volatile object).
...
10 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.

Answer 3

In 6.3.1.8 (usual arithmetic conversions, n1570), we can read

Otherwise, the integer promotions are performed on both operands. Then the following rules are applied to the promoted operands:

so integer promotion is part of the usual arithmetic conversions for integer types.

Thus in the abstratc machine, the conversion to (unsigned) int must be done.

But by the "as if" rule, if the behaviour is indistinguishable from that by strictly implementing the abstract machine, the implementation may do things differently.

So if it is guaranteed that the computation using only single bytes has the same result as the computation promoting to int, the implementation is allowed to use single-byte arithmetic.

Answer 4

If the computer is capable of performing operations on types smaller than int, then by all means the standard will never prevent it. Keep in mind that the standard tries to keep as many options available to the compilers and leaves the decision to choose the best method up to them.

The phrase "no arithmetic is done by C at a precision shorter than int" is also correct. If you pay close attention, you will see that the arithmetic is indeed done at a precision that is no shorter than int. That doesn't mean however that the compiler is forced to do an integer promotion as it can safely perform the operation in your example program on bytes and get the same precision.

Answer 5

I think there is no contradiction here. The compiler is not obliged to follow any specific computation path as long as the observable result is as if it would follow the prescribed way.

In particular, for your case, if we would do the computation with promotion to int (say, to 16 bit): a promoted to int has the same value, so does b as well. The value of a + b is actually (a + b) mod 2^16, but we assign this to an unsigned char, which is truncating the upper 8 bits, that is the same as taking the result mod 2^8: ((a + b) mod 2^16) mod 2^8 = (a + b) mod 2^8.

The calculation without integer promotion would result in (a + b) mod 2^8, which is exactly the same.