5 ms·
> isalnum wouldn't necessarily return true for, say, ç in the french locale (I've no idea what it actually does). It returns true, otherwise "advance to the ne
by bonzini 6y ago
> isalnum wouldn't necessarily return true for, say, ç in the french locale (I've no idea what it actually does).
It returns true, otherwise "advance to the next word" or "grep -w" would be utterly broken. ("grep -w ça" would not match anything, and in fact it probably won't match anything under musl).
Other European languages also treat characters with diacritics as separate letters, for example the Czech alphabet has 42 letters (one of which is "ch" which doesn't have its own Unicode character as far as I remember; if it did there would be more fun to be had with normalization and title case).
> And Musl just plain assumes the C locale, it clearly has no support whatsover for anything else.
Yeah what I meant is that if you are reading UTF-8 you won't be passing chars in the 128-255 range to the ctype functions. But musl doesn't implement Unicode wchar_t either.
- masklinn 6y ago> Yeah what I meant is that if you are reading UTF-8 you won't be passing chars in the 128-255 range to the ctype functions. But musl doesn't implement Unicode wchar_t either. The trap is that ctype functions take int, that's exactly the mistake TFAA made: they passed in an integer assuming isalnum would work with codepoints (which doesn't actually make sense since int is only required to be 16 bits).
- mwcampbell 6y ago> But musl doesn't implement Unicode wchar_t either. It looks like it does. iswalpha uses some kind of table to return its response. Is that implementation somehow too simplistic?
- bonzini 6y agoYou're right I looked up only iswalnum and iswdigit, and trusted masklinn on the rest. :-) So I remembered right, musl assumes an encoding of Unicode where 128-255 is invalid.