[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fix libunistring in MS-Windows locales
From: |
Eli Zaretskii |
Subject: |
Re: Fix libunistring in MS-Windows locales |
Date: |
Sat, 19 Jul 2014 10:11:07 +0300 |
> From: Daiki Ueno <address@hidden>
> Cc: address@hidden, address@hidden
> Date: Sat, 19 Jul 2014 08:11:11 +0900
>
> Eli Zaretskii <address@hidden> writes:
>
> > . __thread works as expected in MinGW GCC since version 4.5.0
> >
> > . DLLs that use __thread (a.k.a. "implicit TLS") cannot be safely
> > loaded at run time, using LoadLibrary, on Windows versions before
> > Vista, they can only be loaded at program startup time (IOW, the
> > corresponding -lLIBRARY switch should be passed on the link
> > command line)
> >
> > . DLLs that need to be able to support LoadLibrary on Windows XP and
> > older need to use explicit TLS API functions, which requires a
> > call to TlsAlloc in the DllMain function, another complication
>
> Thanks for checking in detail. Then it would make more sense to use
> locking rather than TLS.
>
> > Actually, I see that libunistring already includes functions for
> > locking (which on Windows wrap the 2 APIs I mentioned above). So I
> > guess it's best to use them.
>
> Yes, could you create a patch in that direction?
Will do.
> By the way, though a minor nitpicking, the indentation in
> gl_locale_name_thread still doesn't look correct (there is a
> variable declaration in the middle of block).
Oops! Here's the trivial patch to fix that:
2014-07-19 Eli Zaretskii <address@hidden>
localename: Enforce declarations before statements.
* localename.c (gl_locale_name_thread): Declare 'lcid' before
the first statement.
diff --git a/lib/localename.c b/lib/localename.c
index bcef8a0..0c33ddc 100644
--- a/lib/localename.c
+++ b/lib/localename.c
@@ -2730,6 +2730,7 @@ gl_locale_name_thread (int category, const char
*categoryname)
if (LC_MIN <= category && category <= LC_MAX)
{
char *locname = setlocale (category, NULL);
+ LCID lcid = 0;
/* If CATEGORY is LC_ALL, the result might be a semi-colon
separated list of locales. We need only one, so we take the
@@ -2741,7 +2742,7 @@ gl_locale_name_thread (int category, const char
*categoryname)
/* Convert locale name to LCID. We don't want to use
LocaleNameToLCID because (a) it is only available since Vista,
and (b) it doesn't accept locale names returned by 'setlocale'. */
- LCID lcid = get_lcid (locname);
+ lcid = get_lcid (locname);
if (lcid > 0)
return gl_locale_name_from_win32_LCID (lcid);
- Re: Fix libunistring in MS-Windows locales, (continued)
- Re: Fix libunistring in MS-Windows locales, Daiki Ueno, 2014/07/16
- Re: Fix libunistring in MS-Windows locales, Eli Zaretskii, 2014/07/16
- Re: Fix libunistring in MS-Windows locales, Daiki Ueno, 2014/07/17
- Re: Fix libunistring in MS-Windows locales, Eli Zaretskii, 2014/07/17
- Re: Fix libunistring in MS-Windows locales, Paul Eggert, 2014/07/17
- Re: Fix libunistring in MS-Windows locales, Daiki Ueno, 2014/07/17
- Re: Fix libunistring in MS-Windows locales, Daiki Ueno, 2014/07/18
- Re: Fix libunistring in MS-Windows locales, Eli Zaretskii, 2014/07/18
- Re: Fix libunistring in MS-Windows locales, Eli Zaretskii, 2014/07/18
- Re: Fix libunistring in MS-Windows locales, Daiki Ueno, 2014/07/18
- Re: Fix libunistring in MS-Windows locales,
Eli Zaretskii <=