Is it safe to use `strstr` to search for multibyte UTF-8 characters in a string?

Question

Following my previous question: Why `strchr` seems to work with multibyte characters, despite man page disclaimer?, I figured out that strchr was a bad choice.

Instead I am thinking about using strstr to look for a single character (multi-byte not char):

const char str[] = "This string contains é which is a multi-byte character";
char * pos = strstr(str, "é"); // 'é' = 0xC3A9: 2 bytes 
printf("%s\n", pos);

Ouput:

é which is a multi-byte character

Which is what I expect: the position of the 1st byte of my multi-byte character.

A priori, this is not the canonical use of strstr but it seems to work well.
Is this workaround safe ? Can you think about any side-effect or special case that would cause a bug ?

[EDIT]: I should precise that I do not want to use wchar_t type and that strings I handle are UTF-8 encoded (I am aware this choice can be discussed but this an irrelevant debate)

Timofei

"A priori, this is not the canonical" Isn't it? It's just a UTF8 encoded string. – Orthodontist

@AdrianoRepetti it doesn't have to be UTF8. – Nyala

It depends, how "normal" your implementation is. The locale-specific multibyte encoding could be UTF-7 (or anything else having state), in which case strstr may yield false positives. – Theirs

I should ask. Why not use proper UTF-8 functions instead of? – Thick

@Thick If you are talking about wchar I got the same question in my previous post ^^ : see why – Timofei

possible duplicate of Does encoding affect the result of strstr() (and related functions) – Maloriemalory

The aspect of UTF-8 should be in the post title and tag as it is a key point in the post. – Beason

check C's strstr function, for instance, will work perfectly as long as both its inputs are valid, null-terminated UTF-8 strings – Gyral

Answer 1

With UTF-8

UTF-8 is designed in such a way that it is immune to partial mismatch of character as shown above and cause any false positive. So it is completely safe to use strstr with UTF-8 coded multibyte characters.

When used with other encodings

strstr is not suitable for strings containing multi-byte characters.

If you are searching for a string that doesn't contain multi-byte character inside a string that contains multi-byte character, it may give false positive. (While using shift-jis encoding in japanese locale, strstr("掘something", "@some") may give false positive)

+---------+----+----+----+
|   c1    | c2 | c3 | c4 |  <--- string
+---------+----+----+----+

     +----+----+----+
     | c5 | c2 | c3 |  <--- string to search
     +----+----+----+

If trailing part of c1 (accidentally) matches with c5, you may get incorrect result. I would suggest using unicode with unicode substring check function or multibyte substring check functions. (_mbsstr for example)

Henni

Helpful answer ! What about strcmp ? – Flair

@virus721 strcmp is absolutely fine as long as 1. No character has byte 0 in it 2. Encoding of both strings is same. – Henni

Answer 2

Modern systems use UTF-8 (or ASCII) as their multibyte encoding, where the use of this function is safe.

To be strictly conforming and make your code work even on old/exotic platforms, you need to take additional problems into account.

First, the good news: In every multibyte encoding, a 0-byte indicates the end of a string, regardless of state. This means, your strstr won’t cause a crash or something, but the result may be wrong.

As an example, consider UTF-7, a 7-bit clean way to encode Unicode. UTF-7 is a multibyte encoding having a shift state, which means how a byte is interpreted may depend on the context where it appears. E.g. (cf. Wikipedia) “£1AKM” is encoded as +AKM-AKM in UTF-7, where the + sign changes the state and the interpretation of letters like A. Doing strstr(str, "AKM") would match the first AKM portion (after the +), although this is part of the encoding of £ and actually should match the AKM portion after the - (setting the shift state back to the initial state).

Theirs

I forgot to precise that I use UTF-8 encoding, but thanks for the tips anyway. – Timofei

"UTF-8 (or ASCII) as their multibyte encoding" -- ASCII is not a multibyte encoding. (It's also not the same as UTF-8.) ASCII covers only characters 0 through 127, each of which easily fits in a single byte. – Stocking