diff options
author | Stefan Krah <skrah@bytereef.org> | 2017-09-22 15:44:58 (GMT) |
---|---|---|
committer | GitHub <noreply@github.com> | 2017-09-22 15:44:58 (GMT) |
commit | ca72589bfabe2fd0e12eebfeb770b6c7a499b3e6 (patch) | |
tree | ed514225793ab4939a63bb04ba12228c2da419bc | |
parent | 5e02c7826f9797fb3add79b608ef51f7a62b3e5a (diff) | |
download | cpython-ca72589bfabe2fd0e12eebfeb770b6c7a499b3e6.zip cpython-ca72589bfabe2fd0e12eebfeb770b6c7a499b3e6.tar.gz cpython-ca72589bfabe2fd0e12eebfeb770b6c7a499b3e6.tar.bz2 |
bpo-31443: Formulate the type slot initialization rules in terms of C99. (#3688)
-rw-r--r-- | Doc/extending/newtypes.rst | 13 | ||||
-rw-r--r-- | Modules/xxmodule.c | 18 |
2 files changed, 16 insertions, 15 deletions
diff --git a/Doc/extending/newtypes.rst b/Doc/extending/newtypes.rst index f0e8985..0e36ba0 100644 --- a/Doc/extending/newtypes.rst +++ b/Doc/extending/newtypes.rst @@ -177,16 +177,9 @@ the module. We'll expand this example later to have more interesting behavior. For now, all we want to be able to do is to create new :class:`Noddy` objects. To enable object creation, we have to provide a :c:member:`~PyTypeObject.tp_new` implementation. In this case, we can just use the default implementation provided by the API -function :c:func:`PyType_GenericNew`. We'd like to just assign this to the -:c:member:`~PyTypeObject.tp_new` slot, but we can't, for portability sake, On some platforms or -compilers, we can't statically initialize a structure member with a function -defined in another C module, so, instead, we'll assign the :c:member:`~PyTypeObject.tp_new` slot -in the module initialization function just before calling -:c:func:`PyType_Ready`:: - - noddy_NoddyType.tp_new = PyType_GenericNew; - if (PyType_Ready(&noddy_NoddyType) < 0) - return; +function :c:func:`PyType_GenericNew`. :: + + PyType_GenericNew, /* tp_new */ All the other type methods are *NULL*, so we'll go over them later --- that's for a later section! diff --git a/Modules/xxmodule.c b/Modules/xxmodule.c index 0764407..c0564ea 100644 --- a/Modules/xxmodule.c +++ b/Modules/xxmodule.c @@ -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 |