[issue9837] ZipFileExt.read() reads more data than requested
New submission from Black Dew black...@gmail.com: ZipFileExt.read() can return more data than requested, unlike file and other file-like objects. This function calls read1() in a loop, passing the original requested size even if part of the data was already read thus reading and returning more than the caller requested. This should be fixed by requesting n-len(buf) or something similar, or at least properly documented. -- components: Library (Lib) messages: 116158 nosy: Black.Dew priority: normal severity: normal status: open title: ZipFileExt.read() reads more data than requested versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9837 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9837] ZipFileExt.read() reads more data than requested
Black Dew black...@gmail.com added the comment: If i follow the logic in read1() correctly it will do that only for files with very low compression ratios (the original sample where i noticed that problem was actually a chunk of encrypted data inside the zip). From the comments referring to with at most one read() system call I would also assume it's OS-specific. Anyway, I've attached a small file that reproduces this behavior on my system (win xp 32bit). When i run it i get AssertionError: Read returned 4097 bytes (4096 requested) -- Added file: http://bugs.python.org/file18860/a.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9837 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6264] Misleading instructions for installing extensions with mingw
New submission from Black Dew black...@gmail.com: This page http://docs.python.org/install/index.html#gnu-c-cygwin-mingw says: These instructions only apply if you’re using a version of Python prior to 2.4.1 with a MinGW prior to 3.0.0 (with binutils-2.13.90- 20030111-1) But it seems that it is still needed for Python 2.6 with MinGW 3.15.2. Without manually generating libpython26.a I can't compile any python extension, geting a bunch of undefined references, for example: c:\mingw\bin\gcc.exe -mno-cygwin -shared -s build\temp.win32-2.6 \Release\zfec\fec.o build\temp.win32-2.6\Release\zfec\_fecmodule.o build\temp.win32-2.6\Release\zfec\_fec.def -LC:\Python26\libs - LC:\Python26\PCbuild -lpython26 -lmsvcr90 -o build\lib.win32-2.6 \zfec\_fec.pyd build\temp.win32-2.6\Release\zfec\_fecmodule.o:_fecmodule.c: (.text+0xefa): undefined reference to `_imp___Py_TrueStruct' build\temp.win32-2.6\Release\zfec\_fecmodule.o:_fecmodule.c: (.text+0xf01): undefined reference to `_imp___Py_TrueStruct' build\temp.win32-2.6\Release\zfec\_fecmodule.o:_fecmodule.c: (.text+0xf08): undefined reference to `_imp___Py_ZeroStruct' build\temp.win32-2.6\Release\zfec\_fecmodule.o:_fecmodule.c: (.text+0xf0f): undefined reference to `_imp___Py_ZeroStruct' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 If I do generate libpython26.a - everythong works fine. -- assignee: georg.brandl components: Documentation, Extension Modules messages: 89244 nosy: bdew, georg.brandl severity: normal status: open title: Misleading instructions for installing extensions with mingw versions: 3rd party, Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6264] Misleading instructions for building extensions with mingw
Black Dew black...@gmail.com added the comment: It seems this was writen to the docs after a discussion here: http://mail.python.org/pipermail/python-dev/2005-October/057717.html As it turns out, MinGW also implemented, in version 3.0.0 (with binutils-2.13.90-20030111-1), features which make the creation of libpython24.a unnecessary It looks like the current version of mingw sees python26.lib and incorrectly uses it. If i remove python26.lib and place python26.dll instead - mingw uses the exports directly from the dll and everything works too (without needing libpython26.a). This should be reflected in the documentation. -- title: Misleading instructions for installing extensions with mingw - Misleading instructions for building extensions with mingw ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6264] Misleading instructions for building extensions with mingw
Black Dew black...@gmail.com added the comment: It seems that the system I was testing on had the ActiveState python distribution installed which does not include libpython26.a I tried installing the official one from python.org and it has libpython26.a and works fine. Sorry about opening the bug at the wrong place :( -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
