On Tue, 2006-11-14 at 13:38 +0100, Bruno Haible wrote: > 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.
The point here would be to modify c_strcasestr so that it can serve as a replacement module. :-) > > 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". I don't think you are qualified to decide in place of the application developer whether the application should handle localized input or not. I'm not advocating to not use them: I'm advocating to let the developer choose. Some of the library/program using GnuLib are used in embedded system where size matter, and where you won't see anything else than standard ASCII as input. -- Yoann Vandoorselaere | Responsable R&D / CTO | PreludeIDS Technologies Tel: +33 (0)8 70 70 21 58 Fax: +33(0)4 78 42 21 58 http://www.prelude-ids.com
