Would you like signs with those chars?

Sometimes code uses a byte as a very short signed integer in one instance, an unsigned integer in another instance, and as a character where sign did not matter in other instances. I do a lot of coding for embedded (and otherwise resource limited) targets, so this comes up a lot; using compact data structures, and on some targets eliminating generation of sign extension instructions can make the difference between an application that fits on the target and code that doesn't fit, and also affects the runtime efficiency of said code. (Anyone who's written firmware for microcontrollers in C can probably back me up on this.)

Back in the 1980s, I gave up explicitly using "char" for anything other than strings and/or API compatibility, and instead moved to a precursor of the types defined by the header file <stdint.h>, which are now "uint8_t" for unsigned and "int8_t" for signed (I think that the non-standard version was just "uint8" and "int8", respectively, but I'm not sure anymore). Not all compiler toolchains included a header file with consistent names, so I had my own. Using this convention, my code was portable between PDP-11, VAX-11, M68000, Intel8086, and Zilog Z8000, all of which I was using at the time, and eventually PPC, DEC Alpha, ARM, and other architectures with a number of different compilers with, at most, a change in a #define for whether "char" was signed or unsigned if the compiler didn't provide a pre-defined macro for that.

When ISO/IEC 9899:1999 (C99) added "<stdint.h>", I switched to using the standard typedef names for new code and my projects included a "include/compat" directory with versions of "stdint.h" and "stdbool.h" (and a few other "standard" header files introduced by C99) to be used for pre-C99 conforming compilers.

Adopting this sort of thing in the kernel at this stage would likely be a herculean task, but for any new software project in C it is trivial to standardize on using typedefs with explicit properties (signed/unsigned, width) where the built-in C types may vary between targets.