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

[Paul Cercueil <paul@crapouillou.net>]

Hi David,

Le jeu., mars 3 2022 at 11:44:42 +0000, David Laight 
<David.Laight@ACULAB.COM> 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