3 ms·
Here's the thing: isalnum has never been a bottleneck in my code. The sum amount of runtime that glibc's optimizations have saved my programs is almost certainl
by ddevault 6y ago
Here's the thing: isalnum has never been a bottleneck in my code. The sum amount of runtime that glibc's optimizations have saved my programs is almost certainly significantly less than the amount of time I had to spend untangling glibc's bullshit when it broke. Isn't "programmer time is more expensive than computer time" the lie that we've built this whole mess on anyway?
And even if you want to use a LUT, other implementations have incorporated a LUT without this segfault issue, for instance plan 9:
https://code.9front.org/hg/plan9front/file/00397858f3d8/sys/include/ctype.h https://code.9front.org/hg/plan9front/file/00397858f3d8/sys/...
https://code.9front.org/hg/plan9front/file/00397858f3d8/sys/src/libc/port/ctype.c https://code.9front.org/hg/plan9front/file/00397858f3d8/sys/...
- minus7 6y agoAbsolutely, isalnum et al are probably never going to be a bottleneck. I was curious whether it even made a difference at all, after all, the naive implementation doesn't really do a lot. And I fully agree with you that this glibc code is awful. As evidenced by the Plan 9 implementation, table lookups can be done simple as well, and probably perform just the same.
- saagarjha 6y agoParsing?
- cygx 6y agoAt first glance, the plan9 code looks broken to me: EOF is commonly defined as -1, which gets converted to unsigned char (ie 0xFF) before lookup. If your encoding uses the full 8-bit codespace, that's the wrong thing to do...
- theamk 6y agoThat’s probably because they do not care about non-US encodings. I dearly wish entire world would run on us-ascii, it would make software so much easier... but unfortunately there are whole countries which disagree with me.
- cycloptic 6y agoSo, why not submit a patch to fix the segfault? Or submit a bug report at least? Bashing other projects might be fun but it's rarely productive.