The equivalent of strtolower() and strtoupper() is implemented in all C libraries I know (yes, including glibc) and I have worked with on various OSes (and since very long!), even if their names change (because of the unfortunate lack of standardization about their interaction with C locales).
The standardisation of these two functions should have already been made since very long, even if the locales support could be limited to the legacy basic C locale with limited functionality, where these functions would just scan characters through strings to convert them with toupper() and to lower(). But then glibc and other libraries wiould have implemented this standard. For now, we still need complex "config" scripts to detect the correct headers to include, or to provide a basic implementation via various macros. The standard C++ "string" package could have then used this standard internally in the methods exposed in its API. I cannot understand this simple effort was never done on such basic functionality needed and used in almost all softwares and OSes. 2014-11-10 19:55 GMT+01:00 Steffen Nurpmeso <[email protected]>: > Philippe Verdy <[email protected]> wrote: > |Successors to convert strings instead of just isolated "characters" > (sorry, > |they are NOT what we need to handle "texts", they are not even equivalent > |to Unicode characters, they are just code units, most often 8-bit with > |"char" or 16-bit only with "wchar_t" !) already exist in all C libraries > |(including glibc), under different names unfortunately (this is the main > |cause why there are complex header files trying to find the appropriate > |name, and providing a "default" basic implementation that just scans > |individual characters to filter them with tolower and toupper: this is a > |bad practice, > > glibc is the _only_ standard C library i know of that supports its > own homebrew functionality regarding the issue (and in a way that > i personally don't want to and will never work with). > Even the newest ISO C doesn't give just any hand, so that no ISO C > programmer can expect to use any standard facility before 2020, if > that is the time, and then operating systems have to adhere to > that standard, and then programmers have to be convinced to use > those functions. > Until then different solutions will have to be used. > > --steffen >
_______________________________________________ Unicode mailing list [email protected] http://unicode.org/mailman/listinfo/unicode
