This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
[RFC] collate_members_wchar_t.cc
- From: Paolo Carlini <pcarlini at unitus dot it>
- To: libstdc++ at gcc dot gnu dot org
- Cc: bkoz at redhat dot com, ncm at cantrip dot org
- Date: Sat, 09 Mar 2002 19:46:00 +0100
- Subject: [RFC] collate_members_wchar_t.cc
Hi,
in fact fixing this, requires, once more, to delve deeply into the interface
between libstdc++-v3 and glibc... I definitely need some help. Consider this:
#include <string.h>
#include <wchar.h>
int main()
{
int cmp, wcmp;
char* one = "Paolo";
char* two = "Carlini";
wchar_t* three = L"Paolo";
wchar_t* four = L"Carlini";
cmp = strcmp(one, two);
/* cmp = 1 */
wcmp = wcscmp(three, four);
/* wcmp = 13 */
return 0
}
This simple testcase shows in a simplified form (i.e., without locales) that for
sure something is wrong with the use we are making of strcoll and wcscoll (or
__strcoll_l and __wcscoll_l for GNU locales): in the wchar_t case the semantics
is /different/ from that of collate::compare which /always/ returns +1, 0 or -1.
However, trying trivially to deal with the problem with something along the
lines:
template<>
int
collate<wchar_t>::_M_compare_helper(const wchar_t* __one,
const wchar_t* __two) const
{
int __cmp = wcscoll(__one, __two);
if (__cmp > 0)
return 1;
else if (__cmp < 0)
return -1;
else return 0;
}
would fix only the assert at line 129, /not/ that at 107, where i1 == 20 (vs i1
== -1 for the corresponding char test).
In the glibc docs I find:
- Function: int wcscmp (const wchar_t *WS1, const wchar_t *WS2)
The `wcscmp' function compares the wide character string WS1
against WS2. The value returned is smaller than or larger than
zero depending on whether the first differing wide character is
WS1 is smaller or larger than the corresponding character in WS2.
I admit to not fully understand it, that is, I do not understand which kind of
computation exactly is performed. Moreover, I could not find in the docs an
explanation of the computation carried out by the corresponding wcscoll, which
is troubling us. In which ways is different?
Without knowing all of this in detail we cannot implement a sensible compare for
wchar_t.
Perhaps we should ask Ulrich?
Ciao,
Paolo.