Re: strstr, strcase, strcasestr, and i18n

[Paul Eggert]

Bruno Haible <address@hidden> writes:

>   - strstr: This function's behaviour is not clearly defined. POSIX says
>     that it compares a "string" with a "sequence of bytes". Which a priori
>     is nonsense, since the elements of strings are characters.

No, elements of "character strings" are characters.  Elements of "strings"
are bytes.  See:

http://www.opengroup.org/susv3/basedefs/xbd_chap03.html#tag_03_92
http://www.opengroup.org/susv3/basedefs/xbd_chap03.html#tag_03_367

So strstr's behavior is clearly defined: it operates on strings (i.e.,
byte strings), not character strings.

>   - strcase (strcasecmp, strncasecmp): Here POSIX talks about two strings,
>     but doesn't mention LC_CTYPE explicitly. Rather it says the results are
>     "unspecified" in real locales.

This also makes sense, once one realizes that plain "string" means
byte string in POSIX.  These functions are well-defined on byte
strings only (and in the POSIX locale to boot).  The results are
unspecified if you use a multibyte locale.

> It was tempting to make a clear API nomenclature: c-str* for the C locale
> emulation, str* for the internationalized functions. But if you're right
> with strstr, then we should find new names for the internationalized versions
> of these functions.

I think we have to find new names, yes.