| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
so fiddle Jeremy's fix to live with that. Also added more comments.
Bugfix candidate (this bug is in all versions of Python, at least since
2.1).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a length-1 Unicode string was in the freelist and it was
uninitialized or pointed to a very large (magnitude) negative number,
the check
unicode_latin1[unicode->str[0]] == unicode
could cause a segmentation violation, e.g. unicode->str[0] is 0xcbcbcbcb.
Fix this in two ways:
1. Change guard befor unicode_latin1[] to test against 256U. If I
understand correctly, the unsigned long used to store UCS4 on my
box was getting converted to a signed long to compare with the
signed constant 256.
2. Change _PyUnicode_New() to make sure the first element of str is
always initialized to zero. There are several places in the code
where the caller can exit with an error before initializing any
of str, which would leave junk in str[0].
Also, silence a compiler warning on pointer vs. int arithmetic.
Bug fix candidate.
|
|
|
|
|
| |
hashing a class that does not define __hash__ but does define a
comparison.
|
|
|
|
|
|
|
| |
The unicode_resize() family only returns -1 or 0 so simply checking
for != 0 is sufficient, but somewhat unclear. Many Python API
functions return < 0 on error, reserving the right to return 0 or 1 on
success. Change the call sites for consistency with these calls.
|
|
|
|
| |
Will backport to 2.2.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
file_truncate(): C doesn't define what fflush(fp) does if fp is open
for update, and the preceding I/O operation on fp was input. On Windows,
fflush() actually changes the current file position then. Because
Windows doesn't support ftruncate() directly, this not only caused
Python's file.truncate() to change the file position (contra our docs),
it also caused the file not to change size.
Repaired by getting the initial file position at the start, restoring
it at the end, and tossing all the complicated micro-efficiency checks
trying to avoid "provably unnecessary" seeks. file.truncate() can't
be a frequent operation, and seeking to the current file position has
got to be cheap anyway.
Bugfix candidate.
|
|
|
|
| |
slice(5).__hash__() now raises a TypeError.
|
|
|
|
| |
Fixes #603724. Will backport to 2.3.
|
|
|
|
| |
(Contributed by George Yoshida.)
|
| |
|
|
|
|
|
|
| |
Adding missing support for '%F'.
Will backport to 2.3.1.
|
|
|
|
| |
If opening a directory, the exception would leak.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
[ 784825 ] fix obscure crash in descriptor handling
Should be applied to release23-maint and in all likelyhood
release22-maint, too.
Certainly doesn't apply to release21-maint.
|
|
|
|
|
|
| |
Fix, by not using n at all in that case.
Needs to be applied to release23-maint, too.
|
|
|
|
|
|
| |
number. This accounts for the 2 refcount leaks per test_complex run
Michael Hudson discovered (I figured only I would have the stomach to
look for leaks in floating-point code <wink>).
|
|
|
|
|
|
|
|
|
|
| |
when an encoding error occurs and the callback name is unknown,
i.e. when the callback has to be called. The problem was that
the fact that the callback has already been looked up was only
recorded in a local variable in charmap_encoding_error(), because
charmap_encoding_error() got it's own copy of the errorHandler
pointer instead of a pointer to the pointer in
PyUnicode_EncodeCharmap().
|
|
|
|
|
|
| |
Check for a[:] = a _before_ calling PySequence_Fast on a.
release23-maint candidate
Reference leak doesn't happen with head of release22-maint.
|
|
|
|
|
|
|
| |
Now test_descr only appears to leak two references & I think this
are in fact illusory (it's to do with things getting resurrected in
__del__ methods & it's easy to be believe confusion occurs when that
happens <wink>). Woohoo!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sure looks like it to me! <wink>
When I run the leak2.py script I posted to python-dev, I only see
three reference leaks in all of test_descr. When I run
test_descr.test_main, I still see 46 leaks. This clearly demands
posting a yelp to python-dev :-)
This certainly should be applied to release23-maint, and in all
likelyhood release22-maint as well.
|
|
|
|
| |
Include a test case that failed for one of my efforts to repair this.
|
|
|
|
| |
module had been compiled. It gives too many spurious warnings.
|
| |
|
|
|
|
|
|
|
| |
The !PyType_Check(base) check snuck in as part of rev 2.215, but was
unrelated to the SF patch that is mentioned in the checkin comment.
The test is currently unnecessary because base is set to the return
value of best_bases(), which returns a type or NULL.
|
|
|
|
|
| |
"print repr(proxy(a))" and "proxy(a)" at an interactive prompt.
Closes SF bug #722763.
|
| |
|
|
|
|
|
| |
defering to the encodings package.
As described in [ 763111 ] mbcs encoding should skip encodings package
|
| |
|
|
|
|
|
|
| |
Submitted By: Christopher A. Craig
Fillin some missing decrefs.
|
| |
|
|
|
|
|
|
| |
The language reference says you must return an int or a bool. This
fix limits the scope of SF bug 759227 (infinite recursion) to
subclasses of int.
|
| |
|
| |
|
|
|
|
|
|
| |
Check the argument to classmethod for callability.
Backport candidate.
|
| |
|
|
|
|
| |
huge start and stop arguments. Add tests.
|
| |
|
|
|
|
|
| |
- don't use min() and max()
- interpret negative start/stop argument like negative slice indices
|
|
|
|
| |
Also, modified UserList.index() to match and expanded the related tests.
|
|
|
|
| |
for SF bug 742860 (the next item).
|
| |
|
|
|
|
|
| |
names. Unfortunately, this is not bulletproof since the module
dictionary can be modified directly.
|
| |
|
|
|
|
| |
or emptying __dict__, just as we do for classic classes.
|
| |
|
|
|
|
|
| |
* Allow tuple re-use
* Call tp_iternext directly
|
|
|
|
|
|
|
| |
float_pow(): Don't let the platform pow() raise -1.0 to an integer power
anymore; at least glibc gets it wrong in some cases. Note that
math.pow() will continue to deliver wrong (but platform-native) results
in such cases.
|