I recently read that
unsigned char x=1;
printf(\"%u\",x);
invokes undefined behaviour since due to the format specifier %u, printf expects
If your platform's int can represent all values than an unsigned char can, then the promotion is to int, otherwise to unsigned int. So it depends on your platform.
As to "why", that's because you're passing x as a variable argument, and the rules of variable arguments say that the standard promotions take place (presumably so as to simplify the implementation).
Since printf uses a variable argument list, the integer promotions are applied to its integer arguments. In any normal C implementation, the integer promotions convert an unsigned char to an int. Then you are formatting an int With a specifier for unsigned int, so the behavior is undefined.
There is no conflict between saying that a character may be used where an integer may be used and the fact that your statement has behavior not defined by the C standard. Although you may use a character in place of an integer, the rules about what may be printed with %u still apply. If using a character results in an integer appropriate for the specifier, the behavior is defined. If using a character results in an integer inappropriate for the specifier, the behavior is not defined by the C standard.
Discussion elsewhere on Stack Overflow concluded that an exotic C implementation might in theory conform to the C standard while having char types (plain, signed, and unsigned) as wide as int types. In such an implementation, and int could not represent all values of an unsigned char, so an unsigned char would have to be promoted to an unsigned int. However, such an implementation would be exotic and troublesome (notably with handling EOF), and you may ignore it in practice.
Since printf uses a variable argument list, it will be unpacked via va_arg. C++ refers to the C standard for va_arg rules. The C99 Standard says the following:
The
va_argmacro expands to an expression that has the specified type and the value of the next argument in the call. The parameterapshall have been initialized by theva_startorva_copymacro (without an intervening invocation of theva_endmacro for the sameap). Each invocation of theva_argmacro modifiesapso that the values of successive arguments are returned in turn. The parameter type shall be a type name specified such that the type of a pointer to an object that has the specified type can be obtained simply by postfixing a*to type. If there is no actual next argument, or if type is not compatible with the type of the actual next argument (as promoted according to the default argument promotions), the behavior is undefined, except for the following cases:
- one type is a signed integer type, the other type is the corresponding unsigned integer type, and the value is representable in both types;
- one type is pointer to void and the other is a pointer to a character type.
Clearly, integer promotions are taken into account when determining whether the actual and expected type match. And signed vs unsigned mismatch is covered by the first bullet point.
Since x = 1 is certainly a value representable by unsigned int, and promotion of unsigned char generates either signed int (if INT_MAX >= UCHAR_MAX) or unsigned int (if INT_MAX < UCHAR_MAX), this is perfectly legal.