[issue6821] incorrect doc for PyBuffer_Release
New submission from egreen : In documentation (c-api/buffer.html): void PyBuffer_Release(PyObject *obj, Py_buffer *view) should be: void PyBuffer_Release(Py_buffer *view) (as per Include/abstract.h) -- assignee: georg.brandl components: Documentation messages: 92165 nosy: egreen, georg.brandl severity: normal status: open title: incorrect doc for PyBuffer_Release versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue6821> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6881] incorrect signature in doc for PyByteArray_Resize
New submission from egreen : in Doc/c-api/bytearray.rst: PyObject* PyByteArray_Resize(PyObject *bytearray, Py_ssize_t len) should be: int PyByteArray_Resize(PyObject *bytearray, Py_ssize_t len) as per Include/bytearrayobject.h -- assignee: georg.brandl components: Documentation messages: 92506 nosy: egreen, georg.brandl severity: normal status: open title: incorrect signature in doc for PyByteArray_Resize versions: Python 2.7, Python 3.1 ___ Python tracker <http://bugs.python.org/issue6881> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6236] os.popen causes illegal seek on AIX in Python 3.1rc
egreen added the comment: The problem is that the fileio struct in Modules/_io/fileio.c defines the 2-bit seekable field as int. >From the C99 standard, ยง6.7.2: for bit-fields, it is implementation-defined whether the specifier int designates the same type as signed int or the same type as unsigned int. Contrary to gcc, both xlc and suncc default to unsigned. Adding 'signed' solves the problem (and also issue #6348). Patch attached. -- nosy: +egreen Added file: http://bugs.python.org/file14944/fileio-seekable.patch ___ Python tracker <http://bugs.python.org/issue6236> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6982] make clean does not remove pickle files
New submission from egreen : make clean and make distclean don't remove the grammar pickles generated by load_grammar in Lib/lib2to3/pgen2/driver.py (Lib/lib2to3/Grammar3.2.0.alpha.0.pickle, Lib/lib2to3/PatternGrammar3.2.0.alpha.0.pickle). Proposed patch attached. It removes all *.pickle files, which I assume is safe. (Patch also corrects a comment.) -- components: 2to3 (2.x to 3.0 conversion tool), Build files: clean-pickles.patch keywords: patch messages: 93049 nosy: egreen severity: normal status: open title: make clean does not remove pickle files versions: Python 3.0, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file14960/clean-pickles.patch ___ Python tracker <http://bugs.python.org/issue6982> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6982] make clean does not remove pickle files
egreen added the comment: These .pickle files aren't created by the tests themselves, but they do show up after running 'make test', or more specifically after running './python Lib/test/regrtest.py -v test_lib2to3'. This is because a grammar generated from a .txt grammar file is cached as a pickle for faster access by load_grammar in Lib/lib2to3/pgen2/driver.py. A pickle file then ends up in the same directory as the .txt file. IMHO, though it may be preferable to remove just the pickle files in Lib/lib2to3, it should never be required for tests to have pickle files already available in the source tree. Instead, the test should create a temporary pickle file, e.g. from a bytes object. Furthermore, binary files shouldn't be versioned without good reason. Thus, removing all pickle files should be safe for the future. -- ___ Python tracker <http://bugs.python.org/issue6982> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6982] make clean does not remove pickle files
egreen added the comment: You are right. Guess I was being a little too dogmatic. :-) I hadn't found those .pck files, because I was only looking for binary files. Here's a new patch proposal. -- Added file: http://bugs.python.org/file14962/clean-grammar-pickles.patch ___ Python tracker <http://bugs.python.org/issue6982> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7065] bytes.maketrans segfaults
New submission from egreen : The new maketrans static method in Python 3.1 segfaults when using byte values > 127. Reproduce: bytes.maketrans(bytes(range(256)), b'X' * 256) Cause: _Py_bytes_maketrans in Objects/bytes_methods.c uses signed int as array index. Fix attached. Also adds test. -- components: Interpreter Core files: maketrans_segfault.patch keywords: patch messages: 93599 nosy: egreen severity: normal status: open title: bytes.maketrans segfaults versions: Python 3.1, Python 3.2 Added file: http://bugs.python.org/file15049/maketrans_segfault.patch ___ Python tracker <http://bugs.python.org/issue7065> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7065] bytes.maketrans segfaults
egreen added the comment: Yes, it should indeed be a Py_ssize_t. New patch. -- Added file: http://bugs.python.org/file15050/bytes_maketrans_2.patch ___ Python tracker <http://bugs.python.org/issue7065> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7080] locale.strxfrm raises MemoryError
New submission from egreen : The strxfrm function in the locale module can potentially raise a MemoryError. The failing malloc is in Modules/_localemodule.c, line 291. This is because the variable n0 of type Py_ssize_t is passed to PyArg_ParseTuple, which expects an int when PY_SSIZE_T_CLEAN is not defined. Patch attached, which also fixes an unrelated memory leak. -- components: Library (Lib) files: strxfrm_MemoryError.patch keywords: patch messages: 93728 nosy: egreen, loewis severity: normal status: open title: locale.strxfrm raises MemoryError type: crash versions: Python 3.1, Python 3.2 Added file: http://bugs.python.org/file15078/strxfrm_MemoryError.patch ___ Python tracker <http://bugs.python.org/issue7080> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7080] locale.strxfrm raises MemoryError
egreen added the comment: Could someone triage this? And review my simple fix? I think it should be a release blocker. It seems to me to be a problem on all 64-bit non-Windows platforms, or any platform if using UCS-4. The 4 high-order bytes of an 8-byte Py_ssize_t variable are not initialized. Thanks. -- components: +Extension Modules -Library (Lib) ___ Python tracker <http://bugs.python.org/issue7080> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7080] locale.strxfrm raises MemoryError
egreen added the comment: All right. The function strcoll also isn't tested (except for issue #3303). I'll look into that one, too. -- ___ Python tracker <http://bugs.python.org/issue7080> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7080] locale.strxfrm raises MemoryError
egreen added the comment: I've added the tests. I found that on Windows, strxfrm has been unavailable in py3k since r61306, because of an omission in PC/pyconfig.h. (cf. patch) In determining whether I should first test for the existence of strcoll (or strxfrm) in the locale module, as was done in TestMiscellaneous, I found this is no longer needed in py3k since r61339. (cf. patch) (In python2 such checks are still necessary.) -- Added file: http://bugs.python.org/file15158/strxfrm_fixes_and_collation_tests.patch ___ Python tracker <http://bugs.python.org/issue7080> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7080] locale.strxfrm raises MemoryError
egreen added the comment: The tests in TestEnUSCollation I added don't work for all encodings (e.g. Asian ones, or ASCII). Now checked for encodings which are known to work. Found and fixed a bug (result not returned) in getpreferredencoding in Lib/locale.py. This test is skipped on Mac, since r30377. I've tested it on 10.3 (PPC), and it passed, so I enabled it again. I did, however, find that FreeBSD and Mac OS X have known bugs in wcscoll and wcsxfrm: http://www.freebsd.org/cgi/man.cgi?query=wcsxfrm (cf. patch) -- Added file: http://bugs.python.org/file15167/strxfrm_fixes_and_collation_tests_2.patch ___ Python tracker <http://bugs.python.org/issue7080> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
