Why C and C++ hate signed char so much?

Question

Why does C allow accessing object using "character type":

6.5 Expressions (C)

An object shall have its stored value accessed only by an lvalue expression that has one ofthe following types:

• a character type.

but C++ only allows char and unsigned char?

3.10 Lvalues and rvalues (C++)

If a program attempts to access the stored value of an object through a glvalue of other than one of the following types the behavior is undefined:

• a char or unsigned char type.

Another portion of signed char hatred (quote from C++ standard):

3.9 Types (C++)

For any object (other than a base-class subobject) of trivially copyable type T, whether or not the object holds a valid value of type T, the underlying bytes making up the object can be copied into an array of char or unsigned char. If the content of the array of char or unsigned char is copied back into the object, the object shall subsequently hold its original value.

And from C standard:

6.2.6 Representations of types (C)

Values stored in non-bit-field objects of any other object type consist of n × CHAR_BIT bits, where n is the size of an object of that type, in bytes. The value may be copied into an object of type unsigned char [n] (e.g., by memcpy); the resulting set of bytes is called the object representation of the value.

I can see many people on stackoverflow saying that is because unsigned char is the only character type that guaranteed to not have padding bits, but C99 Section 6.2.6.2 Integer types says

signed char shall not have any padding bits

So what is the real reason behind this?

Answer 1

Here's my take on the motivation:

On a non-twos-complement system, signed char will not be suitable for accessing the representation of an object. This is because either there are two possible signed char representations which have the same value (+0 and -0), or one representation that has no value (a trap representation). In either case, this prevents you from doing most meaningful things you might do with the representation of an object. For example, if you have a 16-bit unsigned integer 0x80ff, one or the other byte, as a signed char, is going to either trap or compare equal to 0.

Note that on such an implementation (non-twos-complement), plain char needs to be defined as an unsigned type for accessing the representations of objects via char to work correctly. While there's no explicit requirement, I see this as a requirement derived from other requirements in the standard.