Message135030
| Author |
sdaoden |
| Recipients |
ixokai, nadeem.vawda, ned.deily, neologix, pitrou, python-dev, sdaoden, skrah, vstinner |
| Date |
2011年05月03日.12:14:38 |
| SpamBayes Score |
1.1385393e-11 |
| Marked as misclassified |
No |
| Message-id |
<20110503121427.GA20353@sherwood.local> |
| In-reply-to |
<1304347999.92.0.289179254047.issue11277@psf.upfronthosting.co.za> |
| Content |
> Should we fix Python 2.7?
> - backport issue #8651
> - use PY_SSIZE_T_CLEAN in zlibmodule.c
I really thought about this over night.
I'm a C programmer and thus:
- Produce no bugs
- If you've produced a bug, fix it at once
- If you've fixed a bug, scream out loud "BUGFIX!" -
or at least incorporate the patch in the very next patch release
But i have no experience with maintaining a scripting language.
My survey of something like this spans about three months now.
And if even such a heavy known bug as #1202 survives at least two
minor releases (2.6 and 2.7) without being fixed, then maybe no
more effort should be put into 2.7 at all.
> 11277-27.1.diff contains "# Issue #10276 - check that inputs
> =4GB are handled correctly.". I don't understand this comment
> because the test uses a buffer of 2 GB + 2 bytes.
> How is it possible to pass a buffer of 2 GB+2 bytes to crc32(),
> whereas it stores the size into an int. The maximum size is
> INT_MAX which is 2 GB-1 byte. It looks like the "i" format of
> PyArg_ParseTuple() doesn't check for integer overflow => issue
> #8651. This issue was fixed in 3.1, 3.2 and 3.3, but not in
> Python 2
11277-27.2.diff uses INT_MAX and thus avoids any such pitfall.
Maybe it brings up memory mapping errors somewhere which i surely
would try fix everywhere i can. |
|