3 ms·

I do get what you're saying, but musl also has to live in many different worlds. Using the example where glibc is trawling into endianness in the post you link

by tyingq 5y ago

I do get what you're saying, but musl also has to live in many different worlds. Using the example where glibc is trawling into endianness in the post you linked, for example. Musl runs on a bunch of different big and little endian router boxes and other unusual use cases. While I haven't tested, I'm guessing that their much simpler isalnum() works fine on all of them. Musl does have a lot less legacy to contend with, and musl is often much slower than glibc, so your point stands, of course.

masklinn 5y ago
> While I haven't tested, I'm guessing that their much simpler isalnum() works fine on all of them. isalnum works fine of both, it only veers off when you get into UB which is UB. If you define “works fine” as “gives correct answers even in ub” then musl’s is completely broken since it only gives correct answers for english in ascii.
- cryptonector 5y ago
  It can't give correct answers for anything other than English in UTF-8 locales. It can't give correct answers for any non-Latin scripts in any locales. The problem is ctype and POSIX. Given that, making ctype only work for ASCII (and maybe EBCDIC if you're really unlucky, which glibc is) is basically sufficient.
  - masklinn 5y ago
    > Given that, making ctype only work for ASCII (and maybe EBCDIC if you're really unlucky, which glibc is) is basically sufficient. Of course, but then why complain that glibc doesn't work outsid of ascii is the point.
    - cryptonector 5y ago
      But that's the issue: glibc's ctype does work beyond ASCII: it works for ISO-8859-*. It's pointless because that's pretty much all it can work for.
- Asooka 5y ago
  Nothing in POSIX mandates that isalnum has to be implemented using UB. It is entirely permissible to return 0 for values out of range. Or -1. Or anything else. POSIX is not part of the C language, if a function's behaviour is not defined for a given input, that's not UB, that's a license for the implementation to do whatever is natural. Which can be crashing embarrassingly, but why would you do that.
  - masklinn 5y ago
    > Nothing in POSIX mandates that isalnum has to be implemented using UB. That is a misunderstanding on your part. Calling isalnum with out-of-range values is UB. Per-spec: "If the argument has any other value, the behavior is undefined.". > It is entirely permissible to return 0 for values out of range. Or -1. Or anything else. Of course it is, it's UB, there's nothing it can't do. > POSIX is not part of the C language, if a function's behaviour is not defined for a given input, that's not UB So a behaviour which is not defined is not an undefined behaviour. Sure. Whatever. > that's a license for the implementation to do whatever is natural. Which can be crashing embarrassingly, but why would you do that. Why wouldn't you? A table-based implementation is flexible, convenient and efficient, and you don't care what happens outside of the function's bounds.
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 ago
  ctype is trivially non-localizable to locales with codesets larger than sizeof(unsigned char) anyways. Maybe the problem here is POSIX.
  - jcelerier 5y ago
    oh 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 ago
      Hmm, 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 ago
  Those 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 ago
    most 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)
- 5y ago

by tyingq 5y ago

masklinn 5y ago

> While I haven't tested, I'm guessing that their much simpler isalnum() works fine on all of them. isalnum works fine of both, it only veers off when you get into UB which is UB. If you define “works fine” as “gives correct answers even in ub” then musl’s is completely broken since it only gives correct answers for english in ascii.

cryptonector 5y ago
It can't give correct answers for anything other than English in UTF-8 locales. It can't give correct answers for any non-Latin scripts in any locales. The problem is ctype and POSIX. Given that, making ctype only work for ASCII (and maybe EBCDIC if you're really unlucky, which glibc is) is basically sufficient.
- masklinn 5y ago
  > Given that, making ctype only work for ASCII (and maybe EBCDIC if you're really unlucky, which glibc is) is basically sufficient. Of course, but then why complain that glibc doesn't work outsid of ascii is the point.
  - cryptonector 5y ago
    But that's the issue: glibc's ctype does work beyond ASCII: it works for ISO-8859-*. It's pointless because that's pretty much all it can work for.
Asooka 5y ago
Nothing in POSIX mandates that isalnum has to be implemented using UB. It is entirely permissible to return 0 for values out of range. Or -1. Or anything else. POSIX is not part of the C language, if a function's behaviour is not defined for a given input, that's not UB, that's a license for the implementation to do whatever is natural. Which can be crashing embarrassingly, but why would you do that.
- masklinn 5y ago
  > Nothing in POSIX mandates that isalnum has to be implemented using UB. That is a misunderstanding on your part. Calling isalnum with out-of-range values is UB. Per-spec: "If the argument has any other value, the behavior is undefined.". > It is entirely permissible to return 0 for values out of range. Or -1. Or anything else. Of course it is, it's UB, there's nothing it can't do. > POSIX is not part of the C language, if a function's behaviour is not defined for a given input, that's not UB So a behaviour which is not defined is not an undefined behaviour. Sure. Whatever. > that's a license for the implementation to do whatever is natural. Which can be crashing embarrassingly, but why would you do that. Why wouldn't you? A table-based implementation is flexible, convenient and efficient, and you don't care what happens outside of the function's bounds.

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 ago
ctype is trivially non-localizable to locales with codesets larger than sizeof(unsigned char) anyways. Maybe the problem here is POSIX.
- jcelerier 5y ago
  oh 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 ago
    Hmm, 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 ago
Those 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 ago
  most 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)
5y ago