RE: [PATCH v3] serial: make uart_console_write->putchar()'s character an unsigned char

From: Paul Cercueil
Date: Thu Mar 03 2022 - 07:28:07 EST


Hi David,

Le jeu., mars 3 2022 at 11:44:42 +0000, David Laight <David.Laight@xxxxxxxxxx> a écrit :
From: Maciej W. Rozycki
Sent: 03 March 2022 11:31
..
It does, but, oh dear, it's a "solution" to a problem we have created in
the first place. Why do we ever want to have signed characters in the TTY
layer, and then to vary between platforms? It's asking for portability
issues.

C 'char' is signed because the pdp/11 byte load sign extended.

That's incorrect. The C standard does say that "the implementation shall define char to have the same range, representation, and behavior as either signed char or unsigned char".

C 'char' is signed on x86 (and MIPS and Sparc etc.). It is unsigned on ARM, PowerPC and Risc-V among others.

I guess some ABI use unsigned char to avoid issues with all
the functions that take/return an int parameter that is
either a 'char' cast to 'unsigned char' or EOF.

EOF is usually (-1) - but doesn't have to be.
But it needs to be different from any value obtained
by casting a 'char' to 'unsigned char'.
(But that may only need to be all characters, not all values of 'char'.)

Is the putchar() callback ever going to be called with EOF? I don't think so.

Then you get the requirement that:
sizeof (int) >= sizeof (short) >= sizeof (char)
which means that it is perfectly valid for all 3 to be the same size [1].
In that case 'unsigned char' promotes to 'unsigned int'
which probably breaks some code.

We're talking about Linux here. Ints are 32-bit.

Cheers,
-Paul