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 #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 #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 #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 #21780 to make the unicodedata module 64-bit safe.

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

New changeset 691ca1694fe7 by Victor Stinner in branch '3.4':
Issue #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 #8677: make the zlib module "ssize_t clean" for parsing
http://hg.python.org/cpython/rev/45dcdd8f3211

New changeset 29198ea1c6d58f87389136b0ac0b8b2318dbac24 by Inada Naoki in branch 'master':
bpo-8677: use PY_SSIZE_T_CLEAN in sqlite (GH-12434)
https://github.com/python/cpython/commit/29198ea1c6d58f87389136b0ac0b8b2318dbac24

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 c5a216e0b97712bf19b4a6b7655c6bf22a367edd by Inada Naoki in branch 'master':
bpo-8677: use PY_SSIZE_T_CLEAN in Modules/_gdbmodule.c (GH-12464)
https://github.com/python/cpython/commit/c5a216e0b97712bf19b4a6b7655c6bf22a367edd

New changeset e9a1dcb4237cb2be71ab05883d472038ea9caf62 by Inada Naoki in branch 'master':
bpo-8677: use PY_SSIZE_T_CLEAN in socketmodule.c (GH-12467)
https://github.com/python/cpython/commit/e9a1dcb4237cb2be71ab05883d472038ea9caf62

New changeset d5f18a63cc2dfe8d0adec8bce384a8c569b0f3dc by Inada Naoki in branch 'master':
bpo-8677: use PY_SSIZE_T_CLEAN in PC/winreg.c (GH-12466)
https://github.com/python/cpython/commit/d5f18a63cc2dfe8d0adec8bce384a8c569b0f3dc

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 cc60cdd9c44dd15e441603ee5f78e09ea3e76929 by Inada Naoki in branch 'master':
bpo-8677: use PY_DWORD_MAX instead of INT_MAX (GH-12469)
https://github.com/python/cpython/commit/cc60cdd9c44dd15e441603ee5f78e09ea3e76929

> 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!

stage: patch review -> resolved

nosy: + vstinner
messages: + msg220733

keywords: + patch