[SECURITY] libidn - locale specific error in test suite
Thu Jan 19 20:17:00 GMT 2017
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(...);
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.
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 604 bytes
Desc: OpenPGP digital signature
More information about the Cygwin-apps