Bruno Haible <[EMAIL PROTECTED]> 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.
