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
