Why do platforms pick signed char? [duplicate]

Question

I see lots of answers about signed/unsigned char but not this exact question so feel free to close/duplicate if there is already an answer.

I'm aware that in C and C++ the data type 'char' can be either signed or unsigned. I know that different platforms choose differently, however x86, and all the other platforms I've personally used chose 'char' to be signed.

It seems to me that there are some minor advantages to choosing an unsigned char, for example you can use the value as an array index if you wish to in order to categorize values, but presumably there are reasons, either language related, or in the target architecture that make signed a better choice.

What are those reasons?

Answer 1

The signed keyword was added in C89. Prior to that point, if you made char and unsigned char the same, there was no way to access a signed char-sized type. Therefore, most early C ABIs defined char to be signed. (Even then, though, there were exceptions — C89 would have mandated that char be signed if there hadn't been any exceptions.)

Since that time, we have had a continuous feedback loop between code assuming that char is signed (because the programmers have never seen an ABI where it isn't, so why bother typing an extra word?) and ABIs defining char as signed to ensure compatibility with as much existing code as possible.

A greenfields language design would make char and int8_t separate fundamental types, but C's importance these days rests on the huge body of existing code; you're not likely to see this change ever.

(Also keep in mind that in 1989 it was still quite common for computers and applications to support only 7-bit ASCII. Thus, the inconveniences of signed char for textual data were much less obvious. Those look-up tables you mention would only have had 128 entries. Having char be 8-bit signed is actually more convenient for programs that work with 7-bit text and use the eighth bit as a per-character flag.)