mbcs codec functions are surrounded by:

#if defined(MS_WINDOWS) && defined(HAVE_USABLE_WCHAR_T)
(especially in unicodeobject.c and _codecsmodule.c)

or

#ifdef MS_WIN32
(in unicodeobject.h)

or

#if defined(MS_WINDOWS) && !defined(__BORLANDC__)
(in timemodule.c)

I think that all of these tests are wrong. We should just check that we are compiling under Windows: mbcs functions don't use the wchar_t type. And it's better to use the same test in all tests (MS_WIN32 vs MS_WINDOWS).

Attached patch replaces all #ifdef (except the one in timemodule.c because I don't know what to do with the BORLAND check, does anyone use this compiler?).

I suppose that my patch doesn't change anything in pratice because mbcs is used in many places and noboby complained that mbcs encoding was missing on Windows.

It's true that for now, MS_WINDOWS implies HAVE_USABLE_WCHAR_T and PyUnicodeObject directly used as a WCHAR array.

I'd prefer a new symbol though. Why not something like HAVE_MBCS_CODEC?

> mbcs functions don't use the wchar_t type.

That's not true. MultiByteToWideChar use LPWSTR, which is a typedef for
wchar_t*.

These functions assume that Py_UNICODE is the same type as WCHAR.

> We should just check that we are compiling under Windows:

-1, see above. In the long run, it would be really good if Python
supported a four-byte Py_UNICODE on Windows - people keep asking for it.

I have been meaning to provide versions of the mbcs codecs for years
that work for UCS-4, but haven't found the time yet to implement them.

have_mbcs.patch: use HAVE_MBCS define instead of different tests to check if the MBCS codec can be used or not. HAVE_MBCS is defined in unicodeobject.h by:

#if defined(MS_WINDOWS) && defined(HAVE_USABLE_WCHAR_T)
#  define HAVE_MBCS
#endif

> > We should just check that we are compiling under Windows:

> -1, see above. In the long run, it would be really good if Python
> supported a four-byte Py_UNICODE on Windows - people keep asking
> for it.

MBCS functions of the Python API are always available on Windows without my patch. I don't know if it's correct or not. Using my patch, they are not available if HAVE_USABLE_WCHAR_T is not defined.

Support 32 bits Py_UNICODE on Windows requires a lot of work because in *many* places (everywhere?) Py_UNICODE* is used as wchar_t*. But it is not the topic of this issue :-)

How do the two patches relate?

> How do the two patches relate?

Oh, I forgot to remove my first patch which was wrong.

Patch version 2, more complete: use HAVE_MBCS everywhere.

Version 3 of the patch:
 - fix initialization of the filesystem encoding if HAVE_MBCS is not set
 - Python fails on the filesystem encoding if it is unable to get the filesystem encoding instead of using UTF-8
 - reorganize the definition of time_clock() function
 - cleanup how TZNAME_ENCODING is defined in timemodule.c

The change on initfsencoding() should be defined in a separated commit.

New changeset 7ce685cda0ae by Victor Stinner in branch 'default':
Issue #9642: Fix filesystem encoding initialization: use the ANSI code page on
http://hg.python.org/cpython/rev/7ce685cda0ae

New changeset 75b18b10064f by Victor Stinner in branch 'default':
Issue #9642: Fix the definition of time.clock() on Windows
http://hg.python.org/cpython/rev/75b18b10064f

New changeset 13e6d3cb2ecd by Victor Stinner in branch 'default':
Issue #9642: Uniformize the tests on the availability of the mbcs codec
http://hg.python.org/cpython/rev/13e6d3cb2ecd