Paul Eggert wrote:
> > But it's important to know that c_strstr (s, "x") is not safe and
> > c_strstr (s, "123") is also not safe. The programmer needs to have the
> > precise criteria.
>
> I don't quite follow this. c_strstr (S, "x") is safe in all cases; it
> never has undefined behavior. I
Bruno Haible <[EMAIL PROTECTED]> writes:
> Therefore most of our "c-*" modules should better be called
> "ascii-*" or "unibyte-*".
But both ASCII and other unibyte locales might say that some bytes are
encoding errors. So none of these names are exactly right. I guess
c-* is as good a name as a
Bruno Haible <[EMAIL PROTECTED]> writes:
> The "nearly an ASCII extension" assumption is so ubiquitous, think of
> (c >= '0') tests and similar. You really find it's worth mentioning?
Digits are a very special case, because the C standard (C89
onward) guarantees that they are in order and contigu
Paul Eggert wrote:
> > /* The functions defined in this file assume the "C" locale and a character
> >set without diacritics (ASCII-US or EBCDIC-US or something like that).
> >Even if the "C" locale on a particular system is an extension of the
> > ASCII
> >character set (like on BeOS,
Thanks, that looks nice, but some quibbles about the comments:
> /* The functions defined in this file assume the "C" locale and a character
>set without diacritics (ASCII-US or EBCDIC-US or something like that).
>Even if the "C" locale on a particular system is an extension of the ASCII
>
The module strstr is internationalized, fine. But there are some cases
where it's overkill and the classical and faster byte-per-byte string
traversal can be used instead. I propose to add a new module c-strstr
in the same philosophy as c-ctype, c-strcase, c-strca
