This is the mail archive of the cygwin-apps mailing list for the Cygwin 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] |
On Jan 19 14:17, Eric Blake wrote: > On 01/19/2017 12:19 PM, Corinna Vinschen wrote: > > >>> The test comes from gnulib, so I'm familiar with ideas on how to try and > >>> whittle it down to a smaller self-contained test. I'll see if I can > >>> spend a moment on it today. > >>> > >> > >> After stepping through a debugger, it looks like this is a bug in gnulib > >> and not cygwin. Gnulib is trying to test that its own function > >> gl_locale_name() can track the use of uselocale() to set a thread-local > >> locale that overrides the global locale. It has platform specific code > >> for various platforms (glibc uses nl_langinfo(), BSD uses querylocale(), > >> Sun uses getlocalename_l() - surprisingly none of the platforms use > >> nl_langinfo_l()!), then falls back to probing the environment. As long > >> as cygwin lacked uselocale(), then probing the environment was correct. > >> But now that cygwin supports uselocale(), the gnulib code needs to add a > >> cygwin-specific clause to its list of various platform methods. > >> > >> I'll propose a patch to upstream gnulib, and cc this list - any project > >> using gnulib will have to backport that patch or wait for a new upstream > >> release of that project that uses newer gnulib if it wants to work > >> around the bug. > > > > Thanks for letting us know! > > Actually, Cygwin (or newlib) will need a patch, too. glibc provides the > macro NL_LOCALE_NAME, which can be used as follows: > > locale = newlocale(...); > uselocale(locale); > nl_langinfo_l(NL_LOCALE_NAME(LC_MESSAGES), locale); > > to recover the name of the LC_MESSAGES portion of the locale object. > > As Cygwin lacks that macro, there is NO way to access the locale name of > what went into constructing a thread-local locale without peeking into > the internal guts of the opaque locale_t object. Question: Why is that needed outside of testcases? If you called newlocale you know how it has been constructed. The info should be available. I have no problems to take glibc emulating stuff, but is there a real-world example? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Attachment:
signature.asc
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |