This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: setlocale causing string comparison bug
- From: Anthony Newnam <anthony at bnovc dot com>
- To: Ryan Arnold <ryan dot arnold at gmail dot com>
- Cc: libc-help at sourceware dot org
- Date: Wed, 1 Jul 2009 16:14:25 -0500
- Subject: Re: setlocale causing string comparison bug
- References: <2cba86720906261127m3f6c1e72ucafbfeff302efd29@mail.gmail.com> <ff4da150907011410v5861b627gc042805b83e3774@mail.gmail.com>
I've narrowed down the problem to ld-collate.c in locales/programs.
If I compile this file with
-fexpensive-optimizations -frename-registers
it works out, but if I compile it with
-fexpensive-optimizations -frename-registers -fno-omit-frame-pointer
then localedef generates an invalid locale-archive.
I'm guessing that the obstack_ calls in ld-collate.c are being
incorrectly compiled, but I don't know how to easily test that.
Any help would be appreciated.
Thanks
On Wed, Jul 1, 2009 at 4:10 PM, Ryan Arnold<ryan.arnold@gmail.com> wrote:
> On Fri, Jun 26, 2009 at 1:27 PM, Anthony Newnam<anthony@bnovc.com> wrote:
>> I am having problems with string comparisons when using setlocale. I
>> am running this on two devices (phones) that have very similar
>> software and one exhibits this problem and the other doesn't. One is a
>> "release build" (e.g. stripped symbols and a couple other things) and
>> one is a "debug build" (opposite). The release does not work and the
>> dev does. They have a locale directory at /usr/share/i18n/locales and
>> it is identical on both. Their environment variables are also
>> identical.
>> Here is a program that shows the problem:
>>
>> #include <glibmm/ustring.h>
>> #include <stdio.h>
>>
>> int main()
>> {
>> ? ?Glib::ustring str1("a1");
>> ? ?Glib::ustring str2("a2");
>> ? ?printf("Result: %i\n", (str1 == str2));
>> ? ?setlocale(LC_ALL, "");
>> ? ?printf("Result: %i\n", (str1 == str2));
>> ? ?return 0;
>> }
>>
>> The first result is 0 and the second is 1.
>>
>> I have been trying to debug glib/glibc/glibmm to determine what is
>> happening differently with little success so far. The chain of events
>> is that == is overloaded to call compare() which calls g_utf8_collate
>> which translates the strings to wchar_t's and then calls wcscoll which
>> is in string/strcoll_l.c in glibc. STRCOLL has a locales array which
>> is different between the two devices, but I don't know. It changes
>> when setlocale(LC_ALL, "") is called.
>>
>> Does anyone know what could cause this?
>
> Hi Anthony, have you learned anything new since posting this?
>