NGINX Unit - universal web app server - a lightweight and versatile open source server that simplifies the application stack by natively executing application code across eight different programming language runtimes.
Due to 'char' (unless explicitly set) being signed or unsigned depending on architecture, e.g on x86 it's signed, while on Arm it's unsigned, this can lead to subtle bugs if you use a plain char as a byte thinking it's unsigned on all platforms (maybe you live in the world of Arm).
What we can do is tell the compiler to treat 'char' as unsigned by default, thus it will be consistent across platforms. Seeing as most of the time it doesn't matter whether char is signed or unsigned, it really only matters when you're dealing with 'bytes', which means it makes sense to default char to unsigned.
The Linux Kernel made this change at the end of 2022.
This will also allow in the future to convert our u_char's to char's (which will now be unsigned) and pass them directly into the libc functions for example, without the need for casting.
Here is what the ISO C standard has to say
From §6.2.5 Types ¶15
The three types char, signed char, and unsigned char are collectively
called the character types. The implementation shall define char to
have the same range, representation, and behavior as either signed
char or unsigned char.[45]
and from Footnote 45)
CHAR_MIN, defined in , will have one of the values 0 or
SCHAR_MIN, and this can be used to distinguish the two options.
Irrespective of the choice made, char is a separate type from the
other two and is not compatible with either.
Due to 'char' (unless explicitly set) being signed or unsigned depending on architecture, e.g on x86 it's signed, while on Arm it's unsigned, this can lead to subtle bugs if you use a plain char as a byte thinking it's unsigned on all platforms (maybe you live in the world of Arm).
What we can do is tell the compiler to treat 'char' as unsigned by default, thus it will be consistent across platforms. Seeing as most of the time it doesn't matter whether char is signed or unsigned, it really only matters when you're dealing with 'bytes', which means it makes sense to default char to unsigned.
The Linux Kernel made this change at the end of 2022.
This will also allow in the future to convert our u_char's to char's (which will now be unsigned) and pass them directly into the libc functions for example, without the need for casting.
Here is what the ISO C standard has to say
From §6.2.5 Types ¶15
The three types char, signed char, and unsigned char are collectively called the character types. The implementation shall define char to have the same range, representation, and behavior as either signed char or unsigned char.[45]
and from Footnote 45)
CHAR_MIN, defined in, will have one of the values 0 or
SCHAR_MIN, and this can be used to distinguish the two options.
Irrespective of the choice made, char is a separate type from the
other two and is not compatible with either.