[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fix libunistring in MS-Windows locales
From: |
Bruno Haible |
Subject: |
Re: Fix libunistring in MS-Windows locales |
Date: |
Fri, 02 Dec 2016 13:53:30 +0100 |
User-agent: |
KMail/4.8.5 (Linux/3.8.0-44-generic; KDE/4.8.5; x86_64; ; ) |
Eli Zaretskii wrote in
<http://lists.gnu.org/archive/html/bug-gnulib/2014-07/msg00003.html>:
> One reason is that libunistring needs to know the codeset of the
> locale, to use it when it converts strings to and from Unicode using
> iconv. However, on Windows the function locale_charset always returns
> the default ANSI codepage, using the GetACP API. That API always
> returns the same codepage regardless of locale changes. The result is
> that when libunistring is passed a string in any encoding incompatible
> with the default system codepage, any calls to libiconv will fail with
> EILSEQ. And since most libunistring functions call libiconv, they all
> fail.
> ...
>
> To fix these problems, I propose the following changes. They have
> been extensively tested using Guile's test suite, in particular the
> i18n.test there.
Thank you very much for these well-tested changes, and explanations!
I see the theoretical possibility of a buffer overrun, so I'll sleep
better with this change:
2016-12-02 Bruno Haible <address@hidden>
localcharset: Avoid theoretical buffer overrun.
* lib/localcharset.c (locale_charset) [WINDOWS_NATIVE]: Don't use the
return value from setlocale if it would lead to a buffer overrun.
diff --git a/lib/localcharset.c b/lib/localcharset.c
index ff192f8..5060aaa 100644
--- a/lib/localcharset.c
+++ b/lib/localcharset.c
@@ -507,7 +507,7 @@ locale_charset (void)
current_locale = setlocale (LC_CTYPE, NULL);
pdot = strrchr (current_locale, '.');
- if (pdot)
+ if (pdot && 2 + strlen (pdot + 1) + 1 <= sizeof (buf))
sprintf (buf, "CP%s", pdot + 1);
else
{
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Fix libunistring in MS-Windows locales,
Bruno Haible <=