On Sat, Nov 22, 2008 at 6:39 AM, Denys Vlasenko <[EMAIL PROTECTED]> wrote: > On Saturday 22 November 2008 07:24, Khem Raj wrote: >> Hmm so this wcsxfrm is guarded by UCLIBC_HAS_LOCALE config option. >> your patch just exposed it. > > If you are saying that I am not guilty that's nice to hear, > bur I am also interested how exactly my patch exposed that.
Well no blame game here. I am just saying that earlier this symbol was exported even if locales were not configured. But now with your patch its doing the right thing. > Can you describe in more details? > >> I thought they should be wide char >> routines and I do have wide char support turned on in config. > > Manpage seems to say that it is locale-related indeed: > > size_t wcsxfrm(wchar_t *restrict ws1, const wchar_t *restrict ws2, > size_t n); > DESCRIPTION > The wcsxfrm() function shall transform the wide-character string > pointed to by ws2 and place the resulting wide-character string into > the array pointed to by ws1. The transformation shall be such that if > wcscmp() is applied to two transformed wide strings, it shall return a > value greater than, equal to, or less than 0, corresponding to the > result of wcscoll() applied to the same two original wide-character > strings. > > The point is, wcscoll() is a locale function: > > The wcscoll() function shall compare the wide-character string pointed > to by ws1 to the wide-character string pointed to by ws2, both inter- > preted as appropriate to the LC_COLLATE category of the current locale. > > thus wcsxfrm() has to understand locale to work properly. yeah thats what I figured out. > > But maybe, if locale support is configured out, wcsxfrm() should > still be present, and work as if C locale is in effect? Yeah probably I should just enable locales end of story. > > -- > vda > _______________________________________________ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
