Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bpo-40777: Initialize PyDateTime_IsoCalendarDateType.tp_base at run-time #20493

Merged
merged 1 commit into from
May 28, 2020
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,2 @@
Initialize PyDateTime_IsoCalendarDateType.tp_base at run-time to avoid
errors on some compilers.
13 changes: 10 additions & 3 deletions Modules/_datetimemodule.c
Original file line number Diff line number Diff line change
Expand Up @@ -3325,7 +3325,7 @@ static PyTypeObject PyDateTime_IsoCalendarDateType = {
.tp_doc = iso_calendar_date__doc__,
.tp_methods = iso_calendar_date_methods,
.tp_getset = iso_calendar_date_getset,
.tp_base = &PyTuple_Type,
// .tp_base = &PyTuple_Type, // filled in PyInit__datetime
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The xxsubtype.c module does this weird thing with a macro called DEFERRED_ADDRESS that always returns 0:

DEFERRED_ADDRESS(&PyList_Type), /* tp_base */

Not sure exactly why it's done that way, though.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's just documentation:

/* We link this module statically for convenience. If compiled as a shared
library instead, some compilers don't allow addresses of Python objects
defined in other libraries to be used in static initializers here. The
DEFERRED_ADDRESS macro is used to tag the slots where such addresses
appear; the module init function must fill in the tagged slots at runtime.
The argument is for documentation -- the macro ignores it.
*/
#define DEFERRED_ADDRESS(ADDR) 0

Would you like to use DEFERRED_ADDRESS instead?

.tp_new = iso_calendar_date_new,
};

Expand Down Expand Up @@ -4079,7 +4079,7 @@ static PyTypeObject PyDateTime_TimeZoneType = {
timezone_methods, /* tp_methods */
0, /* tp_members */
0, /* tp_getset */
&PyDateTime_TZInfoType, /* tp_base */
0, /* tp_base; filled in PyInit__datetime */
0, /* tp_dict */
0, /* tp_descr_get */
0, /* tp_descr_set */
Expand Down Expand Up @@ -6458,7 +6458,8 @@ static PyTypeObject PyDateTime_DateTimeType = {
datetime_methods, /* tp_methods */
0, /* tp_members */
datetime_getset, /* tp_getset */
&PyDateTime_DateType, /* tp_base */
0, /* tp_base; filled in
PyInit__datetime */
0, /* tp_dict */
0, /* tp_descr_get */
0, /* tp_descr_set */
Expand Down Expand Up @@ -6524,6 +6525,12 @@ PyInit__datetime(void)
if (m == NULL)
return NULL;

// `&...` is not a constant expression according to a strict reading
// of C standards. Fill tp_base at run-time rather than statically.
// See https://bugs.python.org/issue40777
PyDateTime_IsoCalendarDateType.tp_base = &PyTuple_Type;
PyDateTime_TimeZoneType.tp_base = &PyDateTime_TZInfoType;
PyDateTime_DateTimeType.tp_base = &PyDateTime_DateType;

PyTypeObject *types[] = {
&PyDateTime_DateType,
Expand Down