I absolutely loathe and despise the arrogant 'your code must be bullshit' attitude that runs throughout this article.<p>When you encounter other peoples' code and it looks a bit complicated, and not the 'obvious and simple' thing, your first thought should never be 'they wrote bullshit code', but instead 'what have I missed? What did I forget to consider for this function?'<p>I don't know anything about the glibc authors, or their code style, but if you go through your life assuming incompetence if someone wrote a function differently to your initial thoughts, then you are an arrogant prick.
I was wondering whether there was a significant performance improvement of the table lookup glibc does over the naive implementation musl has.<p>The answer is a pretty big yes. Glibc's isalnum is about 6-7 times faster than musl's.<p>Benchmark code: <a href="https://paste.sr.ht/~minus/18b44cfe58789bc1fb69494130e859a1189d1772" rel="nofollow">https://paste.sr.ht/~minus/18b44cfe58789bc1fb69494130e859a11...</a>
Man, the condescension pouring off from the post.<p>>So the fix is obvious at this point. Okay, fine, my bad. My code is wrong. I apparently cannot just hand a UCS-32 codepoint to isalnum and expect it to tell me if it’s between 0x30-0x39, 0x41-0x5A, or 0x61-0x7A.<p>If that's what you want, just go ahead and write that.
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.
I am wondering what would happen, if someone swapped out the glibc implementation? Would this uncover the deeper technical reason for the implementation? Would suddenly bugs occur elsewhere?<p>It probably just shows how old the glibc is and like most software entropy is increasing over time.