> I think the bug is here. Using SysAllocString instead of
> SysAllocStringLen I get:
>
> VarBstrCmp returns 1
> CompareStringW returns 2
Using SysAllocString, I get that the length of each string is 0.
So yeah, they'd be equal.
So, I'm back to where I started: in Windows, these are different
c
Juan Lang wrote:
You missed the two collation_table lookups.
You're right, I did miss that.
Note that on Windows using CompareString on L"\0001\0002" and
L"\0002\0001" gives a result of CSTR_EQUAL, so I don't think the bug is
in the collation tables.
Really? For which locale
> You missed the two collation_table lookups.
You're right, I did miss that.
> Note that on Windows using CompareString on L"\0001\0002" and
> L"\0002\0001" gives a result of CSTR_EQUAL, so I don't think the bug is
> in the collation tables.
Really? For which locale, and which version of Wind
Juan Lang wrote:
I'm trying to figure out why CompareStringA returns CSTR_EQUAL for the strings "\1" and
"\2". (See bug 5469, and the todo_wine test case in dlls/kernel/tests/locale.c)
CompareStringA does the usual thing, calls MultiByteToWideChar and calls CompareStringW. So
CompareStringW
- Original Message -
From: "Juan Lang" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, June 28, 2006 12:20 AM
Subject: Debugging string comparison problem
I'm trying to figure out why CompareStringA returns CSTR_EQUAL for the strings "\1" and "\2"
I'm trying to figure out why CompareStringA returns CSTR_EQUAL for the strings
"\1" and "\2". (See bug 5469, and the todo_wine test case in
dlls/kernel/tests/locale.c)
CompareStringA does the usual thing, calls MultiByteToWideChar and calls
CompareStringW. So CompareStringW is comparing L"\00
