← 返回首页
bpo-1635741: Fix refleaks of timemoudle in PyInit_time() by shihai1991 · Pull Request #18486 · python/cpython · GitHub
Skip to content

Navigation Menu

Toggle navigation
Sign in
Appearance settings
Search or jump to...

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Include my email address so I can be contacted

Saved searches

Use saved searches to filter your results more quickly

Appearance settings
Resetting focus

bpo-1635741: Fix refleaks of timemoudle in PyInit_time()#18486

Merged
vstinner merged 2 commits into
python:masterfrom
shihai1991:bpo_1635741_14
Mar 11, 2020
Merged

bpo-1635741: Fix refleaks of timemoudle in PyInit_time()#18486
vstinner merged 2 commits into
python:masterfrom
shihai1991:bpo_1635741_14

Conversation

shihai1991 commented Feb 12, 2020
edited by bedevere-bot
Loading

Copy link
Copy Markdown
Member

Copy link
Copy Markdown
Member Author

cc @brandtbucher
Due to brandt have doing some refactoring work of PyModule_AddObject() ;)

brandtbucher left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment

Thanks for your work on this! Looks good, just one question below:

Comment thread Modules/timemodule.c Outdated Show resolved Hide resolved
brandtbucher added the type-bug An unexpected behavior, bug, or error label Feb 12, 2020
Comment thread Modules/timemodule.c

#ifdef CLOCK_REALTIME
PyModule_AddIntMacro(m, CLOCK_REALTIME);
if (PyModule_AddIntMacro(m, CLOCK_REALTIME) < 0) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment

Is the reason that you need goto in every one of these blocks that PyErr_Occcurred() will get reset if you make other PyModule_AddIntMacro calls that don't fail along the way?

Either way, I'm mildly tempted to suggest adding a wrapper macro like:

#define _PyModule_AddIntMacroOrGotoError(m, macro) \ if (PyModule_AddIntMacro(m, macro) < 0) { goto error; }

But I dunno. I'm torn between the principles of "don't repeat yourself" and "don't write a preprocessor macro with a goto in it (you monster)".

brandtbucher Feb 12, 2020
edited
Loading

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment

Between the two options, I'm personally +0 on repetition. Incorrect error handling for the whole PyModule_Add family of functions is rampant in the stdlib (see my work in bpo-38823), and I think reinforcing the correct usage is good to have to keep people from repeating the same old patterns (especially in outside projects).

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment

Is the reason that you need goto in every one of these blocks that PyErr_Occcurred() will get reset if you make other PyModule_AddIntMacro calls that don't fail along the way?

No, I just try to make the Py_DECREF(m);return NULL; looks like a common processing item.

I think reinforcing the correct usage is good to have to keep people from repeating the same old patterns

+1

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment

I dislike macros hiding a goto. A goto statement is dangerous, I prefer to make it explicit. The "if (...) { goto error; }" is a very common pattern in Python, especially in initialization code.

vstinner merged commit 196f1eb into python:master Mar 11, 2020

Copy link
Copy Markdown
Member

Thanks @shihai1991, I merged your PR.

farazs-github pushed a commit to MediaTek-Labs/cpython that referenced this pull request Nov 12, 2021
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

skip news type-bug An unexpected behavior, bug, or error

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants

Footer

© 2026 GitHub, Inc.