Show Posts
1
Ideas / Unsigned char
« on: August 30, 2015, 12:27:27 AM »
Hello everyone,
I'm very pleased with Bas initiative to simplify and extend the C language, fixing some of the shortcomings while keeping the spirit.
Choosing as the base types the fixed bit size signed and unsigned integers and IEEE floating point types is quite pragmatic. Interestingly, it does not prevent users from defining some of the standard C type names such as float, double, int, short and long as aliases.
Regarding the char type, I believe it should be an alias for uint8 instead of int8 as proposed currently.
I completely agree that char should be an 8 bit type, but making it signed is a big source of problems.
Most current C compilers offer a switch to select between signed and unsigned char for the naked char type but sadly default to signed char. This choice probably linked to compatibility reasons for historic code, but it is inconsistent with the rest of the C specification:
getc() for instance returns an int with a value set of 0..UCHAR_MAX plus EOF: comparing the return value from getc() to a char variable or even a character literal will fail for non ASCII characters and might even mistakenly match EOF.
The macros defined in <ctype.h> also take an int with the same set of values: passing a char to these macros is incorrect for non ASCII values. The glibc implementation performs dirty tricks to prevent erratic behaviour by using tables with 384 entries where 257 would suffice.
Making char unsigned seems the only consistent choice for Unicode too: code points are positive as well, in the range 0..0x10FFFF.
Conversely, I fail to see any advantage in making char signed by default. Historic code is not an issue, and programmers should only use the char type for actual character strings, and uint8 or int8 for variable and arrays of bytes. int8 and uint8 are standard types in C2, so using char for this is not the default choice.
Lastly, I think char*, int8* and uint8* should be incompatible pointer types. I'm not sure if that's the case with the current specification.
I'm very pleased with Bas initiative to simplify and extend the C language, fixing some of the shortcomings while keeping the spirit.
Choosing as the base types the fixed bit size signed and unsigned integers and IEEE floating point types is quite pragmatic. Interestingly, it does not prevent users from defining some of the standard C type names such as float, double, int, short and long as aliases.
Regarding the char type, I believe it should be an alias for uint8 instead of int8 as proposed currently.
I completely agree that char should be an 8 bit type, but making it signed is a big source of problems.
Most current C compilers offer a switch to select between signed and unsigned char for the naked char type but sadly default to signed char. This choice probably linked to compatibility reasons for historic code, but it is inconsistent with the rest of the C specification:
getc() for instance returns an int with a value set of 0..UCHAR_MAX plus EOF: comparing the return value from getc() to a char variable or even a character literal will fail for non ASCII characters and might even mistakenly match EOF.
The macros defined in <ctype.h> also take an int with the same set of values: passing a char to these macros is incorrect for non ASCII values. The glibc implementation performs dirty tricks to prevent erratic behaviour by using tables with 384 entries where 257 would suffice.
Making char unsigned seems the only consistent choice for Unicode too: code points are positive as well, in the range 0..0x10FFFF.
Conversely, I fail to see any advantage in making char signed by default. Historic code is not an issue, and programmers should only use the char type for actual character strings, and uint8 or int8 for variable and arrays of bytes. int8 and uint8 are standard types in C2, so using char for this is not the default choice.
Lastly, I think char*, int8* and uint8* should be incompatible pointer types. I'm not sure if that's the case with the current specification.