5 ms·
The author describes ctype.h as "kind of a letdown" and as "not sufficient for international text processing" and then proceeds to write an isalpha() that's not
by avar 8y ago
The author describes ctype.h as "kind of a letdown" and as "not sufficient for international text processing" and then proceeds to write an isalpha() that's not portable C because he assumes an ASCII derivative (the code won't work under e.g. an EBCDIC system).
A lot of things in the C Standard Library look odd or pointless until you do some digging and realize that they were often designed to be portable to systems that are either really obscure today, or don't exist anymore.
- begriffs 8y agoYou mean where I'm comparing whether the character is between 'a' and 'z'? Yeah I'm aware that's an ASCII thing, and that the standard was designed to accommodate other encodings such as EBCDIC. My `isalpha` example was more about showing how such a macro ought to be careful to not evaluate its argument more than once. Did you read the rest of that section? I have arguments about why ctype appears to be insufficient.
- avar 8y agoI just meant to add a bit of info to an already excellent overview, not to detract from it. Yes, most of the rest of the section is about unrelated pitfalls. The non-ASCII use-case is something that's often forgotten these days, and until you mentioned it here there was no indication in the document that you were aware of it. I.e. the section discusses "non-English" non-8-bit languages etc. But the most basic use of ctype.h is e.g. checking if something is in the 0-9a-zA-Z range for the purposes of a basic parser, and you can't do that portably in C without ctype.h, or effectively writing your own ctype.h implementation.
- begriffs 8y ago> until you mentioned it here there was no indication in the document that you were aware of it Good point, and thanks for pointing it out. People can't read my mind and the example might give people the wrong idea. I'll add a note to the example.