Re: Strange character in file length

Alain Bench <veronatif@xxxxxxx> writes:

> Call setlocale(LC_ALL, ".OCP") which will select the default OEM
> charset of the current Windows language. OCP means "OEM Code Page",
> and console apps by default need to use this OEM charset: Probably
> CP-852 for you, CP-850 for me, and so on. Here this setlocale .OCP
> returns "French_France.850".
>
> Another possibly better way, able to follow the current charset of
> the console (not only the default):

Is the "current charset of the console" ever really different than the
"default OEM charset"?  How does one change the console charset,
anyway?

> Call GetConsoleOutputCP(), get example 850, build a string ".850"
> with the dot, and call setlocale(LC_ALL, ".850"). Problem: Not every
> combination of language, country, and charset is possible. So deal
> with errors (setlocale returns NULL), and fallback to ".OCP".

Thanks for the detailed description.  In that case, the setlocale
invocation should look like this:

#ifdef WINDOWS
  {
    char console_code_page[32];
    snprintf (console_code_page, sizeof console_code_page,
              ".%u", GetConsoleOutputCP ());
    if (!setlocale (LC_ALL, console_code_page))
      setlocale (LC_ALL, ".OCP");
  }
#else
  setlocale (LC_ALL, "");
#endif

But I've now noticed another issue: Wget is calling setlocale(LC_ALL,
"") only if HAVE_NLS is defined, which is typically not the case on
Windows, as HAVE_NLS implies existence of gettext, textdomain, and
bindtextdomain.

Along with the above patch, someone should also try to move the call
to setlocale() outside #ifdef HAVE_NLS -- maybe that would be enough
to fix the problem.  Testers able to compile Wget and reproduce this
problem would be much appreciated.