Perhaps the glibc implementation could be simplified a bit, but by the sounds of things musl's version is not functionally equivalent, it only supports ASCII?
C's implementation of locales is certainly a disaster, but so long as they're still in the standard, it surprises me that a serious libc can get away with not supporting them.
I take the opposite tack, a serious libc should just ignore locale requirements because complete disuse is the only way to force the standards committee to fix the spec.
In the "C" locale, it is required only to support ASCII. "In the 'C' locale, isalpha returns true only for the characters for which isupper or islower is true." N2176 7.4.1.1. "In the 'C' locale, islower returns true only for the lowercase letters (as defined in 5.2.1)." 7.4.1.7. "In the 'C' locale, isupper returns true only for the uppercase letters (as defined in 5.2.1)." 7.4.1.11. Section 5.2.1 in turn only defines "the 26 [basic] uppercase letters of the Latin alphabet [and] the 26 [basic] lowercase letters of the Latin alphabet." 5.2.1(3).
Even when a specific locale is set, it can only support ANSI, since the value must be representable as an unsigned char.
To do anything like the "right answer" in a Unicode world, you need to cast to wide int (wint_t) and call iswalpha, which is likely to be almost as broken. A thing that happens is that C libraries will rely on OS locale character set definitions, which in turn won't be installed except for those languages that are installed. You don't want Armenian Linux? Well guess you can't tell what's punctuation vs what's a letter anymore.
The classic glibc int nonsense with the isXXX() checks, and their unchecked array access. This comes up every 2nd week or so, and they refuse to fix it.
7 comments
[ 0.28 ms ] story [ 24.1 ms ] threadEven when a specific locale is set, it can only support ANSI, since the value must be representable as an unsigned char.
To do anything like the "right answer" in a Unicode world, you need to cast to wide int (wint_t) and call iswalpha, which is likely to be almost as broken. A thing that happens is that C libraries will rely on OS locale character set definitions, which in turn won't be installed except for those languages that are installed. You don't want Armenian Linux? Well guess you can't tell what's punctuation vs what's a letter anymore.