In the C++11 standard, why leave the char type implementation dependent?

Question

Background

Several C++ source materials and stack overflow questions talk about the implementation dependent nature of char . That is, char in C++ may be defined as either an unsigned char or a signed char , but this implementation depends entirely on the compiler according to the ARM Linux FAQ:

The above code is actually buggy in that it assumes that the type "char" is equivalent to "signed char". The C standards do say that "char" may either be a "signed char" or "unsigned char" and it is up to the compilers implementation or the platform which is followed.

This leaves the door open for both ambiguity issues and bad practices including mistaking the signage of a char when used as an 8-bit number. The Rationale for C offers some reason for why this is the case, but does not address the issue of leaving open the possibility for ambiguity:

Three types of char are specified: signed, plain, and unsigned. A plain char may be represented as either signed or unsigned, depending upon the implementation, as in prior practice. The type signed char was introduced to make available a one-byte signed integer type on those systems which implement plain char as unsigned. For reasons of symmetry, the keyword signed is allowed as part of the type name of other integral types.

It would seem advantageous to close the door to even the potential of ambiguity to leave only the types of unsigned char and signed char as the two data types for the 8-bit unit. This prompted me to ask the question...

Question

Given the potential for ambiguity, why leave the char data type implementation dependent?

Answer 1

Some processors prefer signed char, and others prefer unsigned char. For example, POWER can load an 8-bit value from memory with zero extension, but not sign extension. But SuperH-3 can load an 8-bit value from memory with sign extension but not zero extension. C++ derives from C, and C leaves many details of the language implementation-defined so that each implementation can be tailored to be most efficient for its target environment.