Explicit cast a pointer difference (intptr_t) to int to fix
two warnings on 64-bit Windows:
Modules\pyexpat.c(1181): warning C4244: 'initializing':
conversion from '__int64' to 'int', possible loss of data
Modules\pyexpat.c(1192): warning C4244: 'initializing':
conversion from '__int64' to 'int', possible loss of data
The C accelerated _elementtree module now initializes hash randomization
salt from _Py_HashSecret instead of libexpat's default CPRNG.
Signed-off-by: Christian Heimes <christian@python.org>
https://bugs.python.org/issue34623
The concrete PyDict_* API is used to interact with PyInterpreterState.modules in a number of places. This isn't compatible with all dict subclasses, nor with other Mapping implementations. This patch switches the concrete API usage to the corresponding abstract API calls.
We also add a PyImport_GetModule() function (and some other helpers) to reduce a bunch of code duplication.
PR #1638, for bpo-28411, causes problems in some (very) edge cases. Until that gets sorted out, we're reverting the merge. PR #3506, a fix on top of #1638, is also getting reverted.
* bpo-29591: Upgrade Modules/expat to libexpat 2.2
* bpo-29591: Restore Python changes on expat
* bpo-29591: Remove expat config of unsupported platforms
Remove the configuration (Modules/expat/*config.h) of unsupported
platforms:
* Amiga
* MacOS Classic on PPC32
* Open Watcom
* bpo-29591: Remove useless XML_HAS_SET_HASH_SALT
The XML_HAS_SET_HASH_SALT define of Modules/expat/expat.h became
useless since our local expat copy was upgrade to expat 2.1 (it's now
expat 2.2.0).
Replace
_PyObject_CallArg1(func, arg)
with
PyObject_CallFunctionObjArgs(func, arg, NULL)
Using the _PyObject_CallArg1() macro increases the usage of the C stack, which
was unexpected and unwanted. PyObject_CallFunctionObjArgs() doesn't have this
issue.
Replace
PyObject_CallFunction(func, "O", arg)
and
PyObject_CallFunction(func, "O", arg, NULL)
with
_PyObject_CallArg1(func, arg)
Replace
PyObject_CallFunction(func, NULL)
with
_PyObject_CallNoArg(func)
_PyObject_CallNoArg() and _PyObject_CallArg1() are simpler and don't allocate
memory on the C stack.
_codecs_cn, _codecs_hk, _codecs_iso2022, _codecs_jp, _codecs_kr and _codecs_tw
modules.
pyexpat.c doesn't need to redeclare PyMODINIT_FUNC, it's already declared in
Include/pyport.h.
to parse more than one XML document per pyexpat xmlparser instance.
(Original patches by Hirokazu Yamamoto and Amaury Forgeot d'Arc, with
suggested wording by David Gutteridge)
in the hash table internal to the pyexpat module's copy of the expat
library to avoid a denial of service due to hash collisions.
Patch by David Malcolm with some modifications by the expat project.
in the hash table internal to the pyexpat module's copy of the expat
library to avoid a denial of service due to hash collisions.
Patch by David Malcolm with some modifications by the expat project.
in the hash table internal to the pyexpat module's copy of the expat
library to avoid a denial of service due to hash collisions.
Patch by David Malcolm with some modifications by the expat project.
Fix readinst() if file.read(n) returns a bytes object longer than n:
return -1 instead of the the buffer size to raise an exception.
Simplify also the function code.
svn+ssh://svn.python.org/python/branches/py3k
........
r85536 | georg.brandl | 2010-10-15 18:26:08 +0200 (Fr, 15 Okt 2010) | 1 line
#9054: fix crash when using pyexpat with a system expat lib version 2.0.1.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r72487 | jeffrey.yasskin | 2009-05-08 17:51:06 -0400 (Fri, 08 May 2009) | 7 lines
PyCode_NewEmpty:
Most uses of PyCode_New found by http://www.google.com/codesearch?q=PyCode_New
are trying to build an empty code object, usually to put it in a dummy frame
object. This patch adds a PyCode_NewEmpty wrapper which lets the user specify
just the filename, function name, and first line number, instead of also
requiring lots of code internals.
........
r72488 | jeffrey.yasskin | 2009-05-08 18:23:21 -0400 (Fri, 08 May 2009) | 13 lines
Issue 5954, PyFrame_GetLineNumber:
Most uses of PyCode_Addr2Line
(http://www.google.com/codesearch?q=PyCode_Addr2Line) are just trying to get
the line number of a specified frame, but there's no way to do that directly.
Forcing people to go through the code object makes them know more about the
guts of the interpreter than they should need.
The remaining uses of PyCode_Addr2Line seem to be getting the line from a
traceback (for example,
http://www.google.com/codesearch/p?hl=en#u_9_nDrchrw/pygame-1.7.1release/src/base.c&q=PyCode_Addr2Line),
which is replaced by the tb_lineno field. So we may be able to deprecate
PyCode_Addr2Line entirely for external use.
........
r72879 | jeffrey.yasskin | 2009-05-23 19:23:01 -0400 (Sat, 23 May 2009) | 14 lines
Issue #6042:
lnotab-based tracing is very complicated and isn't documented very well. There
were at least 3 comment blocks purporting to document co_lnotab, and none did a
very good job. This patch unifies them into Objects/lnotab_notes.txt which
tries to completely capture the current state of affairs.
I also discovered that we've attached 2 layers of patches to the basic tracing
scheme. The first layer avoids jumping to instructions that don't start a line,
to avoid problems in if statements and while loops. The second layer
discovered that jumps backward do need to trace at instructions that don't
start a line, so it added extra lnotab entries for 'while' and 'for' loops, and
added a special case for backward jumps within the same line. I replaced these
patches by just treating forward and backward jumps differently.
........
Jeroen Demeyer
Serhiy Storchaka
Victor Stinner
Zackery Spytz
Christian Heimes
Eric Snow
Victor Stinner
Larry Hastings
Antoine Pitrou
Brett Cannon
Ned Deily
Christian Heimes
Eli Bendersky
Georg Brandl
Gregory P. Smith
Martin v. Löwis
Victor Stinner
Benjamin Peterson
Ezio Melotti
Alexander Belopolsky
Alexandre Vassalotti
Matthias Klose
Mark Dickinson