3 ms·
musl's "isalpha" is trivially wrong, for instance it wouldn't support "ç" (0xe7) or "ß" (0xdf) in ISO 8859-1 which are both alphabetic characters which fit in a
by jcelerier 5y ago
musl's "isalpha" is trivially wrong, for instance it wouldn't support "ç" (0xe7) or "ß" (0xdf) in ISO 8859-1 which are both alphabetic characters which fit in an unsigned char.
- cryptonector 5y agoctype is trivially non-localizable to locales with codesets larger than sizeof(unsigned char) anyways. Maybe the problem here is POSIX.
- jcelerier 5y agooh yes, no code written in 2021 should use that mess. but a glibc being some level of posix compatibility.. hard to blame them for at least trying to make it work.
- cryptonector 5y agoHmm, well, I mean, if ctype can't work for any interesting non-ASCII (and non-EBCDIC) cases (no one should still be using ISO-8859 locales...)... maybe stop trying so hard?
- tyingq 5y agoThose both return 0 for isalpha() on glibc for me, with or without export LC_CTYPE=iso_8859_1 Is there some other setup I'd need to do to see it work in glibc?
- jcelerier 5y agomost likely you need to build the locale on your system (uncomment the relevant line in /etc/locale.gen and run sudo locale-gen). here #include <ctype.h> #include <locale.h> #include <stdio.h> int main(int argc, char** argv) { setlocale(LC_CTYPE, "fr_FR.iso88591"); if(isalpha('ç')) printf("ok\n"); } prints ok (with the file in the correct encoding)
- _kst_ 5y agoisalpha() works with the "C" locale unless you first call setlocale(). For example, on my system isalpha(0xe7) is true if I first call setlocale(LC_ALL, "en_US.iso88591").
- jcelerier 5y agowell, yes, in "normal" C programs you're supposed to fetch the locale from the user's env vars (with setlocale (LC_ALL, ""))