Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

zlibmodule.c isn't 64-bit clean #52896

Closed
pitrou opened this issue May 7, 2010 · 8 comments
Closed

zlibmodule.c isn't 64-bit clean #52896

pitrou opened this issue May 7, 2010 · 8 comments
Labels
extension-modules C modules in the Modules dir type-bug An unexpected behavior, bug, or error

Comments

@pitrou
Copy link
Member

pitrou commented May 7, 2010

BPO 8650
Nosy @loewis, @gpshead, @pitrou, @vstinner

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 2011-05-14.23:09:19.761>
created_at = <Date 2010-05-07.17:20:59.410>
labels = ['extension-modules', 'type-bug']
title = "zlibmodule.c isn't 64-bit clean"
updated_at = <Date 2011-05-14.23:09:19.757>
user = 'https://github.com/pitrou'

bugs.python.org fields:

activity = <Date 2011-05-14.23:09:19.757>
actor = 'nadeem.vawda'
assignee = 'none'
closed = True
closed_date = <Date 2011-05-14.23:09:19.761>
closer = 'nadeem.vawda'
components = ['Extension Modules']
creation = <Date 2010-05-07.17:20:59.410>
creator = 'pitrou'
dependencies = []
files = []
hgrepos = []
issue_num = 8650
keywords = []
message_count = 8.0
messages = ['105216', '106584', '125283', '128984', '131611', '135988', '135998', '136002']
nosy_count = 7.0
nosy_names = ['loewis', 'gregory.p.smith', 'pitrou', 'vstinner', 'nadeem.vawda', 'rcoyner', 'python-dev']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue8650'
versions = ['Python 3.1', 'Python 3.2', 'Python 3.3']
@pitrou
Copy link
Member Author

pitrou commented May 7, 2010

zlibmodule.c doesn't define PY_SSIZE_T_CLEAN, and uses lots of "int" variables for length values internally.
Besides, the zlib itself uses "uInt" and "uLong" variables in its z_stream structure (rather than something guaranteed to be at least the width of a pointer).

On large input data, this will conspire to produce bogus results or crashes. For example:

>>> s = 'x' * (4 * 1024**3 + 100)
>>> t = zlib.compress(s, 1)
>>> len(t)
12
>>> len(zlib.decompress(t))
100

@pitrou pitrou added extension-modules C modules in the Modules dir type-bug An unexpected behavior, bug, or error labels May 7, 2010
@vstinner
Copy link
Member

See also a related issue: bpo-8651.

@vstinner
Copy link
Member

vstinner commented Jan 4, 2011

Fixed by r87729.

Wait for the buildbots before backporting to other versions.

@vstinner
Copy link
Member

Woops, I removed a duplicate message of Antoine. in this issue instead of bpo-8651. Removed message:
-----

Fixed by r87729.

This only addresses the compress() and decompress() functions, but e.g. crc32() and adler32() are also touched by this issue.
-----

@vstinner
Copy link
Member

This only addresses the compress() and decompress() functions,
but e.g. crc32() and adler32() are also touched by this issue.

crc32() and adler32() were fixed by bpo-10276.

PyZlib_objcompress() and PyZlib_objdecompress() should be fixed.

@python-dev
Copy link
Mannequin

python-dev mannequin commented May 14, 2011

New changeset 850624632e9a by Nadeem Vawda in branch '3.1':
Issue bpo-8650: Backport 64-bit safety fixes for compress() and decompress().
http://hg.python.org/cpython/rev/850624632e9a

New changeset 99a3ce22c1ff by Nadeem Vawda in branch '3.2':
Null merge (bpo-8650): zlib.compress() and .decompress() are already 64-bit safe.
http://hg.python.org/cpython/rev/99a3ce22c1ff

New changeset dea5fcdc9ecd by Nadeem Vawda in branch 'default':
Null merge (bpo-8650): zlib.compress() and .decompress() are already 64-bit safe.
http://hg.python.org/cpython/rev/dea5fcdc9ecd

@python-dev
Copy link
Mannequin

python-dev mannequin commented May 14, 2011

New changeset 0b5211d19a14 by Nadeem Vawda in branch '3.1':
Issue bpo-8650: Make zlib.[de]compressobj().[de]compress() 64-bit clean.
http://hg.python.org/cpython/rev/0b5211d19a14

New changeset 3ff862d05d18 by Nadeem Vawda in branch '3.2':
Merge: bpo-8650: Make zlib.[de]compressobj().[de]compress() 64-bit clean.
http://hg.python.org/cpython/rev/3ff862d05d18

New changeset f86a22b6ab58 by Nadeem Vawda in branch 'default':
Merge: bpo-8650: Make zlib.[de]compressobj().[de]compress() 64-bit clean.
http://hg.python.org/cpython/rev/f86a22b6ab58

@nadeemvawda
Copy link
Mannequin

nadeemvawda mannequin commented May 14, 2011

Fixed in 3.1, 3.2 and 3.3.

2.7 no longer has this problem -- the fix for bpo-8651 ensures that the
functions cannot receive inputs large enough to be problematic (since we
don't define PY_SSIZE_T_CLEAN).

@nadeemvawda nadeemvawda mannequin closed this as completed May 14, 2011
@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
extension-modules C modules in the Modules dir type-bug An unexpected behavior, bug, or error
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@vstinner @pitrou