Repository navigation
Enhancement request: make pycore_cell.h compile cleanly under C++ #144490
Description
Activity
What is the error message? What is your compiler (name/version)?
I think most compilers error or warn for this pattern in C++: https://gcc.godbolt.org/z/dvsoqvPzd
Typically with something like:
GCC:
<source>:8:18: error: invalid conversion from 'void*' to 'Foo*' [-fpermissive] 8 | return malloc(sizeof(Foo)); | ~~~~~~^~~~~~~~~~~~~ | | | void* Compiler returned: 1Clang:
<source>:8:12: error: cannot initialize return object of type 'Foo *' with an rvalue of type 'void *' 8 | return malloc(sizeof(Foo)); | ^~~~~~~~~~~~~~~~~~~Reacted by Alperclang version 19.1.2, it should be similar for other compilers, C++ is stricter on implicit conversions.
internal/pycore_cell.h:56:13: error: assigning to 'PyObject *' (aka '_object *') from incompatible type 'void *' 56 | value = _Py_atomic_load_ptr(&cell->ob_ref); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated.- added a commit that references this issue
on Feb 9, 2026 - added 4 commits that reference this issue
on Feb 10, 2026 I modified test_cext (C) and test_cppext (C++) to test the internal C API on 3.14 and main branches. test_cppext now includes the
pycore_cell.hheader file.Currently, test_cppext skips
pycore_backoff.handpycore_cell.hsince they include mimalloc which emits C++ compiler warnings.- added 4 commits that reference this issue
on Feb 15, 2026 - added 4 commits that reference this issue
on Apr 25, 2026
This isn’t a “real issue” report, since
pycore_cell.h(and the helpers it declares) are internal implementation details, so I understand they’re not part of the stable/public API, not guaranteed to be C++-compatible, and may change or disappear in future CPython versions. I’m still asking about this because the fix is very small.While adapting CinderX to FT-Python, we include
pycore_cell.hfrom a C++ (in the JIT/codegen path forLOAD_DEREF/STORE_DEREF). This currently fails to compile under C++ unless-fpermissiveis used.pycore_cell.halready hasextern "C"guards, so it looks intended to be usable from C++ in at least some capacity. Would it be acceptable to add an explicit cast so it compiles cleanly under C++?``Linked PRs