Skip to content

gh-145497: Check _Py_NUM_MANAGED_STATIC_EXTRA_TYPES at runtime - #157582

Open
vstinner wants to merge 2 commits into
python:mainfrom
vstinner:static_extra_types
Open

vstinner wants to merge 2 commits into
python:mainfrom
vstinner:static_extra_types

Conversation

@vstinner

@vstinner vstinner commented Sep 15, 2026

Copy link
Copy Markdown
Member

In debug mode, _Py_NUM_MANAGED_PREINITIALIZED_TYPES, _Py_NUM_STATIC_EXCEPTIONS and _Py_NUM_MANAGED_STATIC_EXTRA_TYPES are now checked with assertions at Python startup to detect if their values is outdated.

Add an array to count static extra types in init_static_type().

In debug mode, _Py_NUM_MANAGED_PREINITIALIZED_TYPES,
_Py_NUM_STATIC_EXCEPTIONS and _Py_NUM_MANAGED_STATIC_EXTRA_TYPES are
now checked with assertions at Python startup to detect if their
values is outdated.

Add an array to count static extra types in init_static_type().
@vstinner

Copy link
Copy Markdown
Member Author

@corona10: Would you mind to review my new PR? This is a new approach which actually counts all static types at Python startup (in debug mode) to make sure that we accounted all static types correctly.

3 macros are now checked at runtime: _Py_NUM_MANAGED_PREINITIALIZED_TYPES, _Py_NUM_STATIC_EXCEPTIONS and _Py_NUM_MANAGED_STATIC_EXTRA_TYPES.

What's left is _Py_MAX_MANAGED_STATIC_EXT_TYPES macro. I didn't understand the purpose of this macro. I don't know if it's related to the number of static types? If we also need to check that this macro is up to date, maybe a separated PR can be written.

Comment on lines 35 to 40

struct static_exception {
PyTypeObject *exc;
const char *name;
};

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.

I think this needs to be wrapped in #ifdef Py_DEBUG as well.

Also, why is this in the header file in the first place? Why not just define it in exceptions.c?

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.

I think this needs to be wrapped in #ifdef Py_DEBUG as well.

This type is also used in release mode by Objects/exceptions.c.

Also, why is this in the header file in the first place? Why not just define it in exceptions.c?

The PR adds count_static_types() in Objects/typeobject.c which does access to extern struct static_exception *_Py_static_exceptions;: it has to know the structure members. Extract:

        for (size_t i=0; i < _Py_num_static_exceptions; i++) {
            if (type == _Py_static_exceptions[i].exc) {
                found = 1;
                break;
            }
        }

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.

Oh, I missed that it was an existing type. Can we rename it to _Py_static_exception or something like that? It's generally uncommon for our header files to expose names that aren't prefixed with _Py.

@corona10 corona10 self-assigned this Sep 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants