This bug happened because: 1) the scanner_search and scanner_match methods
were not checking the buffer limits before increasing the current pointer;
and 2) SRE_SEARCH was using "if (ptr == end)" as a loop break, instead of
"if (ptr >= end)".
* Modules/_sre.c
(SRE_SEARCH): Check for "ptr >= end" to break loops, so that we don't
hang forever if a pointer passing the buffer limit is used.
(scanner_search,scanner_match): Don't increment the current pointer
if we're going to pass the buffer limit.
* Misc/NEWS
Mention the fix.
* Lib/distutils/command/bdist_rpm.py
(bdist_rpm.initialize_options): Included verify_script attribute.
(bdist_rpm.finalize_package_data): Ensure that verify_script is a filename.
(bdist_rpm._make_spec_file): Included verify_script in script_options
tuple.
* Misc/NEWS
Mention change.
Make keyname raise ValueError if passed -1, avoiding a segfault
Make getkey() match the docs and raise an exception in nodelay mode
The return type of getch() is int, not chtype
from Greg Chapman.
* Modules/_sre.c
(lastmark_restore): New function, implementing algorithm to restore
a state to a given lastmark. In addition to the similar algorithm used
in a few places of SRE_MATCH, restore lastindex when restoring lastmark.
(SRE_MATCH): Replace lastmark inline restoring by lastmark_restore(),
function. Also include it where missing. In SRE_OP_MARK, set lastindex
only if i > lastmark.
* Lib/test/re_tests.py
* Lib/test/test_sre.py
Included regression tests for the fixed bugs.
* Misc/NEWS
Mention fixes.
where in lax parsing, the first non-header line after a header block
(e.g. the first line not containing a colon, and not a continuation),
can be treated as the first body line, even without the RFC mandated
blank line separator.
rfc822 had this behavior, and I vaguely remember problems with this,
but can't remember details. In any event, all the tests still pass,
so I guess we'll find out. ;/
This patch works by returning the non-header, non-continuation line
from _parseheader() and using that as the first header line prepended
to fp.read() if given. It's usually None.
We use this approach instead of trying to seek/tell the file-like
object.
multipart/digest isn't a message/rfc822. This is legal, but counter
to recommended practice in RFC 2046, $5.1.5.
The fix is to look at the content type after setting the default
content type. If the maintype is then message or multipart, attach
the parsed subobject, otherwise use set_payload() to set the data of
the other object.
The last round boosted "the limit" from 2GB to 4GB. This round gets
rid of the 4GB limit. For files > 4GB, gzip stores just the last 32
bits of the file size, and now we play along with that too. Tested
by hand (on a 6+GB file) on Win2K.
Boosting from 2GB to 4GB was arguably enough "a bugfix". Going beyond
that smells more like "new feature" to me.
blocked in select(), this will raise select.error with errno set to
EINTR. The except clauses correctly ignores this error, but the rest
of the logic will then call read() for all objects in select's *input*
list of read file descriptors. Then when an object's read_handler()
is naive, it will call recv() on its socket, which will raise an
IOError, and then asyncore decides to close the socket. To fix this,
we simply return in this case.
Backport candidate.