| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem of checking too eagerly for recursive calls is the
following: if a RuntimeError is caused by recursion, and if code needs
to normalize it immediately (as in the 2nd test), then
PyErr_NormalizeException() needs a call to the RuntimeError class to
instantiate it, and this hits the recursion limit again... causing
PyErr_NormalizeException() to never finish.
Moved this particular recursion check to slot_tp_call(), which is not
involved in instantiating built-in exceptions.
Backport candidate.
|
| |
|
|
|
|
| |
typeobject.c.
|
| |
|
|
|
|
|
|
|
|
| |
arguments in reverse, the interpreter would infinitely recourse trying to get a
coercion that worked. So put in a recursion check after a coercion is made and
the next call to attempt to use the coerced values.
Fixes bug #992017 and closes crashers/coerce.py .
|
| |
|
|
|
|
|
|
| |
CRT error handler and disable the assertion for debug builds. This causes CRT to set errno to EINVAL.
This update fixes crash cases in the test suite where the default CRT error handler would cause process exit.
|
|
|
|
| |
at the NeedForSpeed sprint.
|
|
|
|
| |
Backport candidate
|
|
|
|
| |
So there doesn't seem to be much point to checking here.
|
|
|
|
| |
Bottom factor out some common code.
|
| |
|
|
|
|
|
|
| |
- update header checks, using autoconf
- provide dummies for getenv, environ, and GetVersion
- adjust MSC_VER check in socketmodule.c
|
|
|
|
| |
PyThreadState_GET() complains if the tstate is NULL, but only in debug mode.
|
|
|
|
| |
Also improve error message on overflow.
|
|
|
|
| |
top of a block.
|
|
|
|
|
|
| |
attribute checked for __call__ itself, and will continue to look until it finds an object without the attribute. This can lead to an infinite recursion.
Closes bug #532646, again. Will be backported.
|
|
|
|
| |
first argument.
|
| |
|
|
|
|
|
|
|
|
|
| |
the char buffer was requested. Now it actually returns the char buffer if
available or raises a TypeError if it isn't (as is raised for the other buffer
types if they are not present but requested).
Not a backport candidate since it does change semantics of the buffer object
(although it could be argued this is enough of a bug to bother backporting).
|
|
|
|
| |
latter can return something that's true.
|
|
|
|
|
|
| |
Give a consistent behavior for comparison and hashing of method objects
(both user- and built-in methods). Now compares the 'self' recursively.
The hash was already asking for the hash of 'self'.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
2*sizeof(size_t) now, not 8. This probably accounts for
current disasters on the 64-bit buildbot slaves.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to each allocated block. This was using 4 bytes for each such
piece of info regardless of platform. This didn't really matter
before (proof: no bug reports, and the debug-build obmalloc would
have assert-failed if it was ever asked for a chunk of memory
>= 2**32 bytes), since container indices were plain ints. But after
the Py_ssize_t changes, it's at least theoretically possible to
allocate a list or string whose guts exceed 2**32 bytes, and the
PYMALLOC_DEBUG routines would fail then (having only 4 bytes
to record the originally requested size).
Now we use sizeof(size_t) bytes for each of a PYMALLOC_DEBUG
build's extra debugging fields. This won't make any difference
on 32-bit boxes, but will add 16 bytes to each allocation in
a debug build on a 64-bit box.
|
| |
|
|
|
|
|
|
|
|
| |
he didn't know this), so merged in some changes I made during
review. Nothing material apart from changing a new `mask` local
from int to Py_ssize_t. Mostly this is repairing comments that
were made incorrect, and adding new comments. Also a few
minor code rewrites for clarity or helpful succinctness.
|
|
|
|
| |
[ 1456209 ] dictresize() vulnerability ( <- backport candidate ).
|
| |
|
| |
|
|
|
|
|
| |
about extra semi-colons. It may have been the HP C compiler.
This file will trigger a bunch of those warnings now.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
a new comment) suggests there are almost certainly large input
integers in all non-binary input bases for which one Python digit
too few is initally allocated to hold the final result. Instead
of assert-failing when that happens, allocate more space. Alas,
I estimate it would take a few days to find a specific such case,
so this isn't backed up by a new test (not to mention that such
a case may take hours to run, since conversion time is quadratic
in the number of digits, and preliminary attempts suggested that
the smallest such inputs contain at least a million digits).
|
|
|
|
| |
subclasses of Exception can be supplied keyword args
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
our lives taking turns rewriting code that works ;-),
get rid of casting illusions by declaring a new variable
with the obvious type.
|
|
|
|
| |
from a (possibly) wider variable.
|
|
|
|
| |
Py_ReprEntr returns an int
|
|
|
|
| |
in comment
|
| |
|
|
|
|
|
|
| |
I don't have a box with nearly enough RAM, or an OS,
that could get close to tickling this, though (requires
a dict w/ at least 2**31 entries).
|
|
|
|
| |
the current behaviour ;-)
|