Skip to content

Modules needing PY_SSIZE_T_CLEAN #52923

Closed
Closed
Modules needing PY_SSIZE_T_CLEAN#52923
Labels
3.8 (EOL)end of lifeextension-modulesC modules in the Modules dirtype-bugAn unexpected behavior, bug, or error

Description

@pitrou
pitrou
opened on May 10, 2010
BPO 8677
Nosy @loewis, @terryjreedy, @mdickinson, @pitrou, @vstinner, @methane, @serhiy-storchaka
PRs
  • bpo-8677: use PY_SSIZE_T_CLEAN in sqlite #12434
  • bpo-8677: use PY_SSIZE_T_CLEAN in Modules/_gdbmodule.c #12464
  • bpo-8677: use PY_SSIZE_T_CLEAN in PC/winreg.c #12466
  • bpo-8677: use PY_SSIZE_T_CLEAN in socketmodule.c #12467
  • bpo-8677: use PY_DWORD_MAX instead of INT_MAX #12469
  • bpo-36381: warn when no PY_SSIZE_T_CLEAN #12473
    		•
    Dependencies
  • bpo-8675: audioop module needs an int -> Py_ssize_t upgrade
    		•
    Files
  • zlibmodule_ssize_t_clean.patch
    		•

    Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
closed_at = <Date 2019-03-20.12:59:38.299>
created_at = <Date 2010-05-10.19:59:39.449>
labels = ['extension-modules', 'type-bug', '3.8']
title = 'Modules needing PY_SSIZE_T_CLEAN'
updated_at = <Date 2019-03-24.05:25:57.287>
user = 'https://github.com/pitrou'

    bugs.python.org fields:

    activity = <Date 2019-03-24.05:25:57.287>
actor = 'serhiy.storchaka'
assignee = 'none'
closed = True
closed_date = <Date 2019-03-20.12:59:38.299>
closer = 'methane'
components = ['Extension Modules']
creation = <Date 2010-05-10.19:59:39.449>
creator = 'pitrou'
dependencies = ['8675']
files = ['35656']
hgrepos = []
issue_num = 8677
keywords = ['patch']
message_count = 25.0
messages = ['105461', '105462', '105464', '105739', '105741', '105755', '105767', '220678', '220733', '220735', '220737', '222040', '338349', '338350', '338355', '338356', '338443', '338447', '338449', '338451', '338456', '338457', '338467', '338480', '338715']
nosy_count = 9.0
nosy_names = ['loewis', 'terry.reedy', 'mark.dickinson', 'pitrou', 'vstinner', 'Arfrever', 'methane', 'python-dev', 'serhiy.storchaka']
pr_nums = ['12434', '12464', '12466', '12467', '12469', '12473']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue8677'
versions = ['Python 3.8']

    Activity

    1. pitrou commented on May 10, 2010

      @pitrou
      pitrou
      on May 10, 2010
      MemberAuthor

      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

    2. pitrou
      added
      extension-modulesC modules in the Modules dir
      type-bugAn unexpected behavior, bug, or error
      on May 10, 2010

    3. pitrou commented on May 10, 2010

      @pitrou
      pitrou
      on May 10, 2010
      MemberAuthor

      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.

    4. loewis commented on May 10, 2010

      @loewis
      loewismannequin
      on May 10, 2010
      Mannequin

      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.

    5. terryjreedy commented on May 14, 2010

      @terryjreedy
      terryjreedy
      on May 14, 2010
      Member

      Mark just fixed audioop in bpo-8675

    6. mdickinson commented on May 14, 2010

      @mdickinson
      mdickinson
      on May 14, 2010
      Member

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

    7. terryjreedy commented on May 14, 2010

      @terryjreedy
      terryjreedy
      on May 14, 2010
      Member

      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?

    8. pitrou commented on May 14, 2010

      @pitrou
      pitrou
      on May 14, 2010
      MemberAuthor

      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.

    9. BreamoreBoy commented on Jun 15, 2014

      @BreamoreBoy
      BreamoreBoymannequin
      on Jun 15, 2014
      Mannequin

      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 :-(

    10. vstinner commented on Jun 16, 2014

      @vstinner
      vstinner
      on Jun 16, 2014
      Member

      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.

    11. vstinner commented on Jun 16, 2014

      @vstinner
      vstinner
      on Jun 16, 2014
      Member

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

    12. vstinner commented on Jun 16, 2014

      @vstinner
      vstinner
      on Jun 16, 2014
      Member

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

    13. python-dev commented on Jul 1, 2014

      @python-dev
      python-devmannequin
      on Jul 1, 2014
      Mannequin

      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

    14. methane commented on Mar 19, 2019

      @methane
      methane
      on Mar 19, 2019
      Member

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

    15. methane commented on Mar 19, 2019

      @methane
      methane
      on Mar 19, 2019
      Member

      Modules/_gdbmmodule.c
      Modules/socketmodule.c

      They use '#' without PY_SSIZE_T_CLEAN yet.

    16. methane
      added
      3.8 (EOL)end of life
      on Mar 19, 2019

    17. serhiy-storchaka commented on Mar 19, 2019

      @serhiy-storchaka
      serhiy-storchaka
      on Mar 19, 2019
      Member

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

    18. vstinner commented on Mar 19, 2019

      @vstinner
      vstinner
      on Mar 19, 2019
      Member

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

    19. methane commented on Mar 20, 2019

      @methane
      methane
      on Mar 20, 2019
      Member

      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?)

    20. methane commented on Mar 20, 2019

      @methane
      methane
      on Mar 20, 2019
      Member

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

    21. methane commented on Mar 20, 2019

      @methane
      methane
      on Mar 20, 2019
      Member

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

    22. methane commented on Mar 20, 2019

      @methane
      methane
      on Mar 20, 2019
      Member

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

    23. vstinner commented on Mar 20, 2019

      @vstinner
      vstinner
      on Mar 20, 2019
      Member

      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 ;-)

    24. methane commented on Mar 20, 2019

      @methane
      methane
      on Mar 20, 2019
      Member

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

    25. methane commented on Mar 20, 2019

      @methane
      methane
      on Mar 20, 2019
      Member

      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.

    26. methane
      closed this as completedon Mar 20, 2019

    27. vstinner commented on Mar 20, 2019

      @vstinner
      vstinner
      on Mar 20, 2019
      Member

      Let's close this long living issue.

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

    28. serhiy-storchaka commented on Mar 24, 2019

      @serhiy-storchaka
      serhiy-storchaka
      on Mar 24, 2019
      Member

      Thank you for doing this Inada-san!

    29. ezio-melotti
      transferred this issue fromon Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    No one assigned

      Labels

      3.8 (EOL)end of lifeextension-modulesC modules in the Modules dirtype-bugAn unexpected behavior, bug, or error

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions