6 ms·
Locale handling and most of the str* function in libc indeed are quite bad. The only sane function for "C strings" is snprintf.
by Cloudef 6y ago
Locale handling and most of the str* function in libc indeed are quite bad. The only sane function for "C strings" is snprintf.
- kazinator 6y agoOnes like strspn, strcspn, strpbrk, strchr are also sane.
- asveikau 6y agoExcept when you consider what a char is. Those don't handle multi-byte sequences.
- kazinator 6y agoYes they do. What they don't do is search for multi-byte characters. You would not use them for that; you use them to look for ASCII delimiters. You can tokenize a UTF-8 string on ASCII delimiters using functions that are oblivious to UTF-8, and this is in fact a preferred technique in many programs.
- asveikau 6y agoI think I was going for more like: strpbrk and friends can't use a multi-byte sequence as a delimiter. And if a delimiter appears as part of a multi byte sequence, you may see strange results. In a localized world searching for delimiters also starts to make less sense. Eg. I have been told it doesn't make sense to break on whitespace for Chinese text. To be clear, I am not saying these functions are bad or evil or to blame for their limitations (a bunch of the problem space wasn't invented yet when they were introduced), just noting they have limits. A bunch of more recent languages and libraries have the same or similar issues, too.
- jesuscyborg 6y agoUse wcspbrk. UTF-8 continuation characters are limited to the range \200 through \300 so there's basically zero chance that if you choose something like comma as your delimiter that it's going to tokenize the middle of a multibyte sequence. Also take into consideration that, under the hood, functions like strpbrk() are typically accelerated by CPU instructions such as PCMPISTRI which doesn't support UTF-8 natively but it does support UCS-2.
- loeg 6y ago> so there's basically zero chance that if you choose something like comma as your delimiter that it's going to tokenize the middle of a multibyte sequence. Not just "basically;" there is no possible collision between ASCII characters and any valid multibyte encoding. This can be seen somewhat visually in this table[1] and is an intentional aspect of the UTF-8 design. [1]: https://en.wikipedia.org/wiki/UTF-8#Encoding https://en.wikipedia.org/wiki/UTF-8#Encoding
- asveikau 6y agoHow about with joiners and combining characters? Eg. If you encode é as U+0065, U+0301 (\x65\xcc\x81), then search for 'e' and act on the result somehow, you fail to consider the whole glyph.
- loeg 6y agoSure. You're talking about glyphs that are composed of multiple unicode codepoints; my earlier comment is true of single codepoints only. The comment I was responding to is also talking only about single codepoints (wcspbrk cannot represent delimiters longer than a single codepoint). On joiners / combining characters: I'd encourage using composed normalization (NFC) rather than decomposed normalization (NFD). Just curiosity: are there any glyphs that lack a single codepoint representation, where one of the joined codepoints is an ASCII character? (That only helps after normalization, of course.)
- jesuscyborg 6y ago
- kazinator 6y agostrstr can find a multi-byte character in a multi-byte sequence. There is no ISO C function to find the first occurrence of any one of a bag of multi-byte characters, though it's not difficult to write one. > I have been told it doesn't make sense to break on whitespace for Chinese text. It could make sense to break on whitespace in some programming language or data format that allows Chinese (and other) identifiers. A command interpreter that allows Chinese arguments (such as file names) wants to break on spaces, as usual. > if a delimiter appears as part of a multi byte sequence, you may see strange results. UTF-8 was designed by a dyed-in-the-wool C-and-Unix engineer, who ensured that such a thing can't happen. No character in the 0x00-0x7F range can occur in a multi-byte character. The byte which starts a UTF-8 character cannot occur anywhere other than at the start, which is why we can use strstr to look for it.
- Cloudef 6y agoTrue. With the snprintf comment I was mostly pointing out str* functions that are designed to either modify or concatenate strings.
- ringshall 6y agoIt's been a long time since I've used C, but I recall strncpy being safe. I assume from context that I'm wrong, though.
- WalterBright 6y agoEvery time I review code and see strncpy, I look closer because it's always used incorrectly. It's always about the terminating 0. Is the 0 there or not? Is the 0 part of n or not? Does the destination have to be n+1 in size for the 0? I quit using it myself because I could never remember just what the exact protocol was for 0.
- Gibbon1 6y agoYeah used naively strncpy leaves you an unterminated string. Also like all of them it's up to the caller to predetermine if they will fail if called. So instead of having the checks in one place inside the string function. You have them scattered all over the code if at all.
- WalterBright 6y agoThe irony of strncpy is it's supposed to eliminate memory corruption errors, but instead is a prolific source of them.
- Gibbon1 6y agoI think I read somewhere the provenience of strncpy was to copy strings into a fixed length field which is why it has the deranged behavior of not terminating the string. Think file systems where the max file name is 8 characters. Or compilers that truncated variable names at 31.
- johntb86 6y agoStrncpy doesn't add a \0 if it truncates the string, so the user has to remember to do that.
- 6y ago