Re: Question about “Uppercase” in DerivedCoreProperties.txt

[Philippe Verdy]

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 <sdaoden at yandex.com>:

> Philippe Verdy <verdy_p at wanadoo.fr> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20141110/da91740d/attachment.html>