> It is used in CSIEscape.buf, Glyph.c etc.
> However, char can be either signed or unsigned depends on the
> architecture.
It depends of the compiler, not of the architecture. Compiler will decide
signess of char based in what can be more efficient or what is
more logical.
> On x86 '\x80' < 0x20 is true, but (uchar)'\x80' < 0x20 is false.
Here you should say that gcc (I suppose you are using it) in x86
evaluate these expressions in this way, but be careful because maybe
another compiler in x86 can do another thing.
> tputc explicitly converts character to ascii code:
> uchar ascii = *c;
It converts it to unsigned char, the character is not translated
from a code to another. Ascii is only a name of a variable.
>
> In tsetchar there is this code:
> c[0] >= 0x41 && c[0] <= 0x7e
> This condition is false for negative chars, so, accidentally, it works
> the same way for signed and unsigned chars.
It is not an accident. C standard ensures that any printable
character has the most significant bit to 0, and this is basically why the
code works, because doesn't matter if char is signed or unsigned. In other
case all the functions of ctype could be not implementable.
> How to reproduce:
> 1. Add the following keybinding:
> { XK_F1, XK_NO_MOD, "\x80" , 0, 0, 0},
> 2. Run st and enable echo mode: printf '\e[12l'
> 3. Press F1. Character '\x80' is recognized as control and ^ is displayed,
> followed by unprintable character.
This is another different problem. St is an utf8 terminal, so
any character with the most significant bit to 1 is part of an
utf8 sequence, so the key assignation you did was incorrect for
an utf8 terminal (it put utf8decoder in an incorrect state).
> Also techo did not recognize DEL as control character and did not
> display ^? for it, this patch fixes this bug too.
This is the part of the patch I like, because it is true that DEL was not
not correctly handled (it is the reason why tputc has this check).
If you modify the commit message and explain the problem with the DEL
as the reason for the commit I will apply it.
Regards,
--
Roberto E. Vargas Caballero
Received on Tue Apr 22 2014 - 22:06:46 CEST