Re: [bug-gnulib] Re: [bug-gnulib] Re: Question concerning c-ctype, c-strcase, c-strcasestr and c-strstr modules

[Bruno Haible]

Yoann Vandoorselaere wrote:
> "However, if we have a platform missing strcasestr, then using
> c_strcasestr as the substitute implementation is probably okay, because
> that platform would probably be broken in other areas, such as locale
> support, ...

Solaris 9 and Solaris 10 (which also doesn't have strcasestr) really
are not broken in the area of locale support. Solaris has good locale
support for years.

> such that a locale-aware replacement strcasestr would not be
> worth the effort."

It's not a question of effort. (The "effort" for you is to put an identifier
into the list of modules that you import from gnulib.) It's a question whether
your application can possibly be handling Chinese text from a Chinese user,
or whether it's handling ASCII English in all cases. In the first case,
you need strcasestr; in the latter case, you need c_strcasestr.

> Also, depending on the program or library using the fallback GnuLib
> module, you might not want a version of the function supporting locale,
> for performance reason or because of the number of dependencies it would
> bring, and the resulting library size. 

I don't think Chinese users will find it nice if you exclude them from
correct functioning of your program because of "performance" or "library size".

> As an example, on a recent Linux system, importing the strcasestr module
> generate a library more than twice the size of one importing
> c_strcasestr.

Yes. This is because even on a recent Linux system, the libc's strcasestr()
does not work right for Chinese strings (in GB18030 or BIG5 encoding for
example).

Bruno