This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: setlocale causing string comparison bug


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?
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]