Black Dew 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
New submission from Black Dew :
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
Black Dew 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
Black Dew 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
New submission from Black Dew :
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 i