Stowage/cpython
2
0
Fork 0
mirror of https://github.com/python/cpython.git synced 2025-12-31 04:23:37 +00:00
Code Issues Projects Releases Packages Wiki Activity

bpo-31443: Formulate the type slot initialization rules in terms of C99. (#3688)

Browse source
This commit is contained in:
Stefan Krah 2017-09-22 17:44:58 +02:00 • committed by GitHub
parent 5e02c7826f
commit ca72589bfa
2 changed files with 15 additions and 14 deletions
Download patch file Download diff file Expand all files Collapse all files

18
Modules/xxmodule.c
View file

@ -308,7 +308,7 @@ static PyTypeObject Null_Type = {
0, /*tp_dictoffset*/
0, /*tp_init*/
0, /*tp_alloc*/
0, /* see PyInit_xx */ /*tp_new*/
PyType_GenericNew, /*tp_new*/
0, /*tp_free*/
0, /*tp_is_gc*/
};
@ -338,11 +338,19 @@ PyDoc_STRVAR(module_doc,
static int
xx_exec(PyObject *m)
{
/* Due to cross platform compiler issues the slots must be filled
* here. It's required for portability to Windows without requiring
* C++. */
/* Slot initialization is subject to the rules of initializing globals.
C99 requires the initializers to be "address constants". Function
designators like 'PyType_GenericNew', with implicit conversion to
a pointer, are valid C99 address constants.
However, the unary '&' operator applied to a non-static variable
like 'PyBaseObject_Type' is not required to produce an address
constant. Compilers may support this (gcc does), MSVC does not.
Both compilers are strictly standard conforming in this particular
behavior.
*/
Null_Type.tp_base = &PyBaseObject_Type;
Null_Type.tp_new = PyType_GenericNew;
Str_Type.tp_base = &PyUnicode_Type;
/* Finalize the type object including setting type of the new type