Ensure we don't write beyond errText. I think I got this right, but
it definitely could use some review to ensure I'm not off by one
and there's no possible overflow/wrap-around of bytes_left.
Reported by Klocwork #1.
Fix a problem if there is a failure allocating self->db.
Found with failmalloc.
Check the allocation of b_objects and return if there was a failure.
Also fix a few memory leaks in other failure scenarios.
It seems that if b_objects == Py_None, we will have an extra ref to
b_objects. Add XXX comment so hopefully someone documents why the
else isn't necessary or adds it in.
Be a lot smarter about whether this test passes: instead of assuming
that a 2.93 sec audio file will always take 3.1 sec (as it did on the
hardware I had when I first wrote the test), expect that it will take
2.93 sec +/- 10%, and only fail if it's outside of that range.
Compute the expected
Barry Warsaw [Fri, 21 Jul 2006 14:51:07 +0000 (14:51 +0000)]
More RFC 2231 improvements for the email 4.0 package. As Mark Sapiro rightly
points out there are really two types of continued headers defined in this
RFC (i.e. "encoded" parameters with the form "name*0*=" and unencoded
parameters with the form "name*0="), but we were were handling them both the
same way and that isn't correct.
This patch should be much more RFC compliant in that only encoded params are
%-decoded and the charset/language information is only extract if there are
any encoded params in the segments. If there are no encoded params then the
RFC says that there will be no charset/language parts.
Note however that this will change the return value for Message.get_param() in
some cases. For example, whereas before if you had all unencoded param
continuations you would have still gotten a 3-tuple back from this method
(with charset and language == None), you will now get just a string. I don't
believe this is a backward incompatible change though because the
documentation for this method already indicates that either return value is
possible and that you must do an isinstance(val, tuple) check to discriminate
between the two. (Yeah that API kind of sucks but we can't change /that/
without breaking code.)
Test cases, some documentation updates, and a NEWS item accompany this patch.
Move the initialization of some pointers earlier. The problem is
that if we call Py_DECREF(frame) like we do if allocating locals fails,
frame_dealloc() will try to use these bogus values and crash.
Updated documentation for TimedRotatingFileHandler relating to how rollover files are named. The previous documentation was wrongly the same as for RotatingFileHandler.
Thomas Heller [Wed, 19 Jul 2006 09:09:32 +0000 (09:09 +0000)]
Make sure the _ctypes extension can be compiled when WITH_THREAD is
not defined on Windows, even if that configuration is probably not
supported at all.
Tim Peters [Wed, 19 Jul 2006 00:03:19 +0000 (00:03 +0000)]
SF bug 1524317: configure --without-threads fails to build
Moved the code for _PyThread_CurrentFrames() up, so it's no longer
in a huge "#ifdef WITH_THREAD" block (I didn't realize it /was/ in
one).
Changed test_sys's test_current_frames() so it passes with or without
thread supported compiled in.
Note that test_sys fails when Python is compiled without threads,
but for an unrelated reason (the old test_exit() fails with an
indirect ImportError on the `thread` module). There are also
other unrelated compilation failures without threads, in extension
modules (like ctypes); at least the core compiles again.
Do we really support --without-threads? If so, there are several
problems remaining.
Fix bug #1520914. Starting in 2.4, time.strftime() began to check the bounds
of values in the time tuple passed in. Unfortunately people came to rely on
undocumented behaviour of setting unneeded values to 0, regardless of if it was
within the valid range. Now those values force the value internally to the
minimum value when 0 is passed in.
Barry Warsaw [Mon, 17 Jul 2006 23:07:51 +0000 (23:07 +0000)]
decode_rfc2231(): Be more robust against buggy RFC 2231 encodings.
Specifically, instead of raising a ValueError when there is a single tick in
the parameter, simply return that the entire string unquoted, with None for
both the charset and the language. Also, if there are more than 2 ticks in
the parameter, interpret the first three parts as the standard RFC 2231 parts,
then the rest of the parts as the encoded string.
Test cases added.
Original fewer-than-3-parts fix by Tokio Kikuchi.
Resolves SF bug # 1218081. I will back port the fix and tests to Python 2.4
(email 3.0) and Python 2.3 (email 2.5).
Also, bump the version number to email 4.0.1, removing the 'alpha' moniker.
Kurt B. Kaiser [Mon, 17 Jul 2006 21:59:27 +0000 (21:59 +0000)]
Patch 1479219 - Tal Einat
1. 'as' highlighted as builtin in comment string on import line
2. Comments such as "#False identity" which start with a keyword immediately
after the '#' character aren't colored as comments.
3. u or U beginning unicode string not correctly highlighted
v2 can be NULL if exception2 is NULL. I don't think that condition can happen,
but I'm not sure it can't either. Now the code will protect against either
being NULL.
Thomas Heller [Fri, 14 Jul 2006 15:01:05 +0000 (15:01 +0000)]
Make the prototypes of our private PyUnicode_FromWideChar and
PyUnicode_AsWideChar replacement functions compatible to the official
functions by using Py_ssize_t instead of int.
Anthony Baxter [Tue, 11 Jul 2006 02:04:09 +0000 (02:04 +0000)]
#1494314: Fix a regression with high-numbered sockets in 2.4.3. This
means that select() on sockets > FD_SETSIZE (typically 1024) work again.
The patch makes sockets use poll() internally where available.
Tim Peters [Mon, 10 Jul 2006 21:08:24 +0000 (21:08 +0000)]
After approval from Anthony, merge the tim-current_frames
branch into the trunk. This adds a new sys._current_frames()
function, which returns a dict mapping thread id to topmost
thread stack frame.