5 ms·

I guess the glibc complexity with a LUT is to support non-ascii character sets? It seems quite silly to compare a general solution to a hard coded special case.

buster 6y ago
I think one major point is the unreadable mess, though. Is there a reason for this?
- rightbyte 6y ago
  Any big standard lib I laid my eyes on (gcc, clang, MS headers) seems to be a mess. I too wonder if the complexity is really necessary, but I guess so? Macros in my experience is ofent to fool the compiler to generate better code. Maybe that is a legacy reason?
  - ThreeFx 6y ago
    99% of the time the answer is speed. It's just way faster to evaluate and build all of this at compile time than at runtime. I understand both sides of the argument here - on one hand you have fast and unreadable code and on the other hand slower and more readable code. The problem here is 1. the leaky abstraction of characters and code points and 2. loss of type safety due to C's weak typing rules, which is a bit lost in the "hurr durr messy code."
  - DaiPlusPlus 6y ago
    Windows.h is still full of obsolete ancient macros that can’t be removed for compatibility. Things like references to near and far pointers (still!) and how every Win32 function with string params is a macro for the real A/W-suffixed functions, and all the A-suffixed functions now intentionally crash on post-98 systems.
    - tjalfi 6y ago
      > all the A-suffixed functions now intentionally crash on post-98 systems. Do you have a source for this claim? I find it hard to believe that Microsoft would drop support for ANSI applications.
- johannes1234321 6y ago
  There are a number of reasons: - Support for weird compilers - Focus on performance, thus playing "weird" tricks with macros, lookup tables etc. - especially in headers: protect against users doing crazy sh*t - standards sometimes change or see extensions - certainly more :) First two items can be re-evaluated form time to time, but especially GNU often aims to run "anywhere" The third item comes from the fact that users can create macros for many things and only some names (leading _ and capital letter or __) are reserved for standards or C++ allowing to overload the comma operator, which can have weird effects. Thus to be conformant to the standards some ugliness is required. The fourth point combined with different compatibility requirements requires tricks to switch between different implementations based on compiler flags/macros (for instance `#define _GNU_SOURCE` or `#define _POSIX_C_SOURCE=...`)
birb007 6y ago
If that were the case, wouldn't a developer either be using uchar types or wchar_t which have their own specific variants of character related functions?
- masklinn 6y ago
  No? Extended-ascii does not require wchar (which is, incidentally, utter dreck) and isalnum is defined as taking > an unsigned char or […] EOF so isalnum is "their own specific variants of character related functions" for uchar, and locale-aware.
  - birb007 6y ago
    Fair point
  - iforgotpassword 6y ago
    But what the duck? How does that make sense for Chinese? This is bullshit. Great, now isalnum returns true for ä if I'm using de_DE.latin1 or whatever, but is still nonsense for any non-western language. And the price we pay for that is a messed up pile of garbage that nobody understands and can segfault.
    - bonzini 6y ago
      It's not just Western languages. It's how text was encoded until the 90s and early 2000s for pretty much every language except Chinese, Japanese and Korean (maybe Thai, I am not sure). That's the "famous" CJK acronym for languages that really did require double byte character sets. For example Russian, Greek, Hebrew, and Indic languages all have alphabets that will fit very easily in 128 codepoints (Vietnamese too, which is Latin but with a large number of diacritics).
      - iforgotpassword 6y ago
        You're right. I faintly remember these times. Japanese even had an 8 bit charset that simply dropped kanji, iirc. But all the platforms that use glibc have moved to utf8 over a decade ago. So even for western languages that code doesn't make sense anymore.

buster 6y ago

I think one major point is the unreadable mess, though. Is there a reason for this?

rightbyte 6y ago
Any big standard lib I laid my eyes on (gcc, clang, MS headers) seems to be a mess. I too wonder if the complexity is really necessary, but I guess so? Macros in my experience is ofent to fool the compiler to generate better code. Maybe that is a legacy reason?
- ThreeFx 6y ago
  99% of the time the answer is speed. It's just way faster to evaluate and build all of this at compile time than at runtime. I understand both sides of the argument here - on one hand you have fast and unreadable code and on the other hand slower and more readable code. The problem here is 1. the leaky abstraction of characters and code points and 2. loss of type safety due to C's weak typing rules, which is a bit lost in the "hurr durr messy code."
- DaiPlusPlus 6y ago
  Windows.h is still full of obsolete ancient macros that can’t be removed for compatibility. Things like references to near and far pointers (still!) and how every Win32 function with string params is a macro for the real A/W-suffixed functions, and all the A-suffixed functions now intentionally crash on post-98 systems.
  - tjalfi 6y ago
    > all the A-suffixed functions now intentionally crash on post-98 systems. Do you have a source for this claim? I find it hard to believe that Microsoft would drop support for ANSI applications.
johannes1234321 6y ago
There are a number of reasons: - Support for weird compilers - Focus on performance, thus playing "weird" tricks with macros, lookup tables etc. - especially in headers: protect against users doing crazy sh*t - standards sometimes change or see extensions - certainly more :) First two items can be re-evaluated form time to time, but especially GNU often aims to run "anywhere" The third item comes from the fact that users can create macros for many things and only some names (leading _ and capital letter or __) are reserved for standards or C++ allowing to overload the comma operator, which can have weird effects. Thus to be conformant to the standards some ugliness is required. The fourth point combined with different compatibility requirements requires tricks to switch between different implementations based on compiler flags/macros (for instance `#define _GNU_SOURCE` or `#define _POSIX_C_SOURCE=...`)

birb007 6y ago

If that were the case, wouldn't a developer either be using uchar types or wchar_t which have their own specific variants of character related functions?

masklinn 6y ago
No? Extended-ascii does not require wchar (which is, incidentally, utter dreck) and isalnum is defined as taking > an unsigned char or […] EOF so isalnum is "their own specific variants of character related functions" for uchar, and locale-aware.
- birb007 6y ago
  Fair point
- iforgotpassword 6y ago
  But what the duck? How does that make sense for Chinese? This is bullshit. Great, now isalnum returns true for ä if I'm using de_DE.latin1 or whatever, but is still nonsense for any non-western language. And the price we pay for that is a messed up pile of garbage that nobody understands and can segfault.
  - bonzini 6y ago
    It's not just Western languages. It's how text was encoded until the 90s and early 2000s for pretty much every language except Chinese, Japanese and Korean (maybe Thai, I am not sure). That's the "famous" CJK acronym for languages that really did require double byte character sets. For example Russian, Greek, Hebrew, and Indic languages all have alphabets that will fit very easily in 128 codepoints (Vietnamese too, which is Latin but with a large number of diacritics).
    - iforgotpassword 6y ago
      You're right. I faintly remember these times. Japanese even had an 8 bit charset that simply dropped kanji, iirc. But all the platforms that use glibc have moved to utf8 over a decade ago. So even for western languages that code doesn't make sense anymore.