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 <br...@clisp.org>
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
{
