Additionally, fix a bug where a MemoryError in allocating a bytes object could
leave the decompressor object in an invalid state (with its unconsumed_tail
member being NULL).
Patch by Serhiy Storchaka.
If the version of zlib used to compile the zlib module is incompatible
with the one that is actually linked in, then calls into zlib will fail.
This can leave attributes of the z_stream uninitialized, so we must take
care to avoid segfaulting by trying to use an invalid pointer.
Fix by Richard M. Tew.
platforms with a 64-bit long.
The Alpha/Tru64 test problem is a problem in either tarfile or test_tarfile,
not zlib.
crc32 and adler32 return 32-bit values. by using a long thats larger than
32-bits in these functions they were prevented from wrapping around to their
signed 32-bit value that we want them to return in python 2.x.
which made the return value signed. On the Alpha that also lost data
since sizeof(int) != sizeof(long) and apparently adler32/crc32 return
64 bits of data. This change keeps the signedness and continues to store the
data in a long rather than an int as was the case before r61449.
regardless of the native sizeof(long) used in the integer object.
This somewhat odd behavior of returning a signed is maintained in 2.x for
compatibility reasons of always returning an integer rather than a long object.
Fixes Issue1202 for Python 2.6
extension implemented flush() was fixed. Scott also rewrite the
zlib test suite using the unittest module. (SF bug #640230 and
patch #678531.)
Backport candidate I think.
The staticforward define was needed to support certain broken C
compilers (notably SCO ODT 3.0, perhaps early AIX as well) botched the
static keyword when it was used with a forward declaration of a static
initialized structure. Standard C allows the forward declaration with
static, and we've decided to stop catering to broken C compilers. (In
fact, we expect that the compilers are all fixed eight years later.)
I'm leaving staticforward and statichere defined in object.h as
static. This is only for backwards compatibility with C extensions
that might still use it.
XXX I haven't updated the documentation.
don't understand how this function works, also beefed up the docs. The
most common usage error is of this form (often spread out across gotos):
if (_PyString_Resize(&s, n) < 0) {
Py_DECREF(s);
s = NULL;
goto outtahere;
}
The error is that if _PyString_Resize runs out of memory, it automatically
decrefs the input string object s (which also deallocates it, since its
refcount must be 1 upon entry), and sets s to NULL. So if the "if"
branch ever triggers, it's an error to call Py_DECREF(s): s is already
NULL! A correct way to write the above is the simpler (and intended)
if (_PyString_Resize(&s, n) < 0)
goto outtahere;
Bugfix candidate.
type.__module__ behavior.
This adds the module name and a dot in front of the type name in every
type object initializer, except for built-in types (and those that
already had this). Note that it touches lots of Mac modules -- I have
no way to test these but the changes look right. Apologies if they're
not. This also touches the weakref docs, which contains a sample type
object initializer. It also touches the mmap test output, because the
mmap type's repr is included in that output. It touches object.h to
put the correct description in a comment.
Apparently this patch (rev 2.41) replaced all the good old "s#"
formats in PyArg_ParseTuple() with "S". Then it did
PyString_FromStringAndSize() to get back the values setup by the
"s#" format. It also incref'd and decref'd the string obtained by
"S" even though the argument tuple had a reference to it.
Replace PyString_AsString() calls with PyString_AS_STRING().
A good rule of thumb -- if you never check the return value of
PyString_AsString() to see if it's NULL, you ought to be using the
macro <wink>.
Many functions used a local variable called return_error, which was
initialized to zero. If an error occurred, it was set to true. Most
of the code paths checked were only executed if return_error was
false. goto is clearer.
The code also seemed to be written under the curious assumption that
calling Py_DECREF() on a local variable would assign the variable to
NULL. As a result, more of the error-exit code paths returned an
object that had a reference count of zero instead of just returning
NULL. Fixed the code to explicitly assign NULL after the DECREF.
A bit more reformatting, but not much.
XXX Need a much better test suite for zlib, since it the current tests
don't exercise any of this broken code.
Nadeem Vawda
Antoine Pitrou
Gregory P. Smith
Christian Heimes
Neal Norwitz
Martin v. Löwis
Tim Peters
Georg Brandl
Andrew M. Kuchling
Guido van Rossum
Mark Hammond
Jeremy Hylton
Fred Drake
Sjoerd Mullender
Jack Jansen