This is a list of extension modules making use of one of the "#" format codes ("s#", "y#", etc.) without defining PY_SSIZE_T_CLEAN, and therefore being 64-bit unclean:

Modules/audioop.c
Modules/_cursesmodule.c
Modules/_elementtree.c
Modules/_gdbmmodule.c
Modules/nismodule.c
Modules/ossaudiodev.c
Modules/pyexpat.c
Modules/socketmodule.c
Modules/_ssl.c
Modules/unicodedata.c

The documentation says that sometimes in the future Py_ssize_t will be the default, so we may also need some kind of transition period for non-complying third-party extensions; first with warnings and then with errors perhaps.

I personally don't think that a transition period would be a useful thing to have, in particular not if it goes like this:

• in version A, require use of PY_SSIZE_T_CLEAN
• in version A+1, make use of PY_SSIZE_T_CLEAN redundant

So I'd rather drop PY_SSIZE_T clean altogether from 3.2, and risk any breakage that this may cause.

Mark just fixed audioop in bpo-8675

And the curses module was made PY_SSIZE_T_CLEAN in r81085 (a very simple change).

Is there any reason why you reported zlibmodule.c separately in bpo-8650 (other than maybe finding that first), and for 4 versions there versus 1 here? Should this supersede that?

Is there any reason why you reported zlibmodule.c separately in bpo-8650
(other than maybe finding that first),

Because zlibmodule.c has more 64-bitness issues than just PY_SSIZE_T_CLEAN (see bug description).

Should this supersede that?

No.

Given the rise of the 64 bit machine I'd guess that this needs completing sooner rather than later. I'd volunteer myself but I've never heard of the '#' format codes, let alone know anything about them :-(

zlibmodule_ssize_t_clean.patch: Patch to make the zlib module "ssize_t clean". The patch just defines PY_SSIZE_T_CLEAN, no "#" format is used. "./python -m test -v test_zlib" test pass on my 64-bit Linux.

I just created the issue bpo-21780 to make the unicodedata module 64-bit safe.

I created the issue bpo-21781 to make the _ssl module 64-bit clean.

New changeset 691ca1694fe7 by Victor Stinner in branch '3.4':
Issue bpo-8677: make the zlib module "ssize_t clean" for parsing parameters
http://hg.python.org/cpython/rev/691ca1694fe7

New changeset 45dcdd8f3211 by Victor Stinner in branch 'default':
(Merge 3.4) Issue bpo-8677: make the zlib module "ssize_t clean" for parsing
http://hg.python.org/cpython/rev/45dcdd8f3211

New changeset 29198ea by Inada Naoki in branch 'master':
bpo-8677: use PY_SSIZE_T_CLEAN in sqlite (GH-12434)
29198ea

Modules/_gdbmmodule.c
Modules/socketmodule.c

They use '#' without PY_SSIZE_T_CLEAN yet.

Also PC/winreg.c. In this case winreg.SetValue() needs a length of size DWORD instead of ssize_t.

Would it be possible to emit a deprecation warning, maybe at runtime, when PY_SSIZE_T_CLEAN is not defined?

Also PC/winreg.c. In this case winreg.SetValue() needs a length of size DWORD instead of ssize_t.

As MSDN, cbData is ignored.
https://docs.microsoft.com/en-us/windows/desktop/api/winreg/nf-winreg-regsetvaluew

Can I skip overflow check?

If I can not, what is DWORD_MAX? (INT_MAX?)

New changeset c5a216e by Inada Naoki in branch 'master':
bpo-8677: use PY_SSIZE_T_CLEAN in Modules/_gdbmodule.c (GH-12464)
c5a216e

New changeset e9a1dcb by Inada Naoki in branch 'master':
bpo-8677: use PY_SSIZE_T_CLEAN in socketmodule.c (GH-12467)
e9a1dcb

New changeset d5f18a6 by Inada Naoki in branch 'master':
bpo-8677: use PY_SSIZE_T_CLEAN in PC/winreg.c (GH-12466)
d5f18a6

PC/winreg.c:

    if (value_length >= INT_MAX) {
        PyErr_SetString(PyExc_OverflowError,
                        "the value is too long");
        return NULL;
    }

PY_DWORD_MAX should be used here. It's twice larger than INT_MAX ;-)

New changeset cc60cdd by Inada Naoki in branch 'master':
bpo-8677: use PY_DWORD_MAX instead of INT_MAX (GH-12469)
cc60cdd

Would it be possible to emit a deprecation warning, maybe at runtime, when PY_SSIZE_T_CLEAN is not defined?

I created bpo-36381 for it. Let's close this long living issue.

Let's close this long living issue.

Thanks INADA-san for fixing last issues and for creating the deprecation issue!

Thank you for doing this Inada-san!