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
